We are using HTTPS and I don't believe this will work over SSL
connections. It would also add a significant overhead since it will
compress every request and every payload.
Zissis Trabaris * Chief Technology Officer * INSYSWARE * 3235 West River
Road, Grand Island, New York, 14072, USA
Mobile (716) 930-5654 * Office (518) 636-4118 * Fax (716) 625-1305 *
z.trabari..nsysware.com * www.insysware.com
CONFIDENTIALITY: This email (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited. If you received this email in error,
please notify the sender and delete this email from your system. Thank
you.
-----Original Message-----
From: Andrus Adamchik [mailto:andru..bjectstyle.org]
Sent: Friday, June 05, 2009 8:59 AM
To: de..ayenne.apache.org
Subject: Re: Initial ROP client query takes way to long
You can delegate this task to your container by using HTTP gzip
compression. E.g. Tomcat can compress the content for you (search for
"compression" on this page) :
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
Other servers can too... The Java client should just pick it up
automatically:
http://www.caucho.com/support/hessian-interest/0506/0003.html
Andrus
On Jun 5, 2009, at 4:00 PM, Zissis Trabaris wrote:
> It's too bad we can't extend DispatchHelper. If we could I could
> define
> a new message called BootstrapZiped and send the client entity
> resolver
> in a compressed format over the wire and then sub class
> ClientChannel to
> send a BootstrapZiped message within getEntityResolver. It should
> not be
> difficult to extend DispatchHelper so that we can register our own
> callbacks and client messages. I wrote a quick and dirty simple
> example
> below if you want to use it:
>
> // Interface that must be implemented when creating a dispatch helper
> callback extension
> interface DispatchHelperCallback {
>
> public Object dispatch(DataChannel channel, ClientMessage message);
> }
>
> class DispatchHelper {
>
> private static ConcurrentHashMap<Class, DispatchHelperCallback>
> registeredCallbacks = new ConcurrentHashMap<Class, Class>();
>
> // Register user defined dispatch helper extensions
> static void registerDispatchHelperCallback(Class messageClass,
> DispatchHelperCallback callback) {
> DispatchHelper.registeredCallbacks.put(messageClass, callback);
> }
>
> static Object dispatch(DataChannel channel, ClientMessage
> message) {
> // do most common messages first...
> if (message instanceof QueryMessage) {
> return channel.onQuery(null, ((QueryMessage)
> message).getQuery());
> }
> else if (message instanceof SyncMessage) {
> SyncMessage sync = (SyncMessage) message;
> return channel.onSync(null, sync.getSenderChanges(),
> sync.getType());
> }
> else if (message instanceof BootstrapMessage) {
> return
> channel.getEntityResolver().getClientEntityResolver();
> }
> // check to see if we have a callback for this message and fire
> it if we do.
> else
> if
> (DispatchHelper.registeredCallbacks.containsKey(message.getClass()) {
> return
> DispatchHelper
> .registeredCallbacks.get(message.getClass()).dispatch(chan
> nel, message);
> }
> else {
> throw new CayenneRuntimeException(
> "Message dispatch error. Unsupported message: " +
> message);
> }
> }
> }
>
> Zissis Trabaris * Chief Technology Officer * INSYSWARE * 3235 West
> River
> Road, Grand Island, New York, 14072, USA
> Mobile (716) 930-5654 * Office (518) 636-4118 * Fax (716) 625-1305 *
> z.trabari..nsysware.com * www.insysware.com
>
> CONFIDENTIALITY: This email (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited. If you received this email in error,
> please notify the sender and delete this email from your system. Thank
> you.
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andru..bjectstyle.org]
> Sent: Friday, June 05, 2009 7:49 AM
> To: de..ayenne.apache.org
> Subject: Re: Initial ROP client query takes way to long
>
> Correct - the first ROP access causes client to load all the mapping
> metadata from the server. I guess the sheer # of tables in your schema
> causes such a delay. To avoid slow bootstrap theoretically it should
> be possible to persist the mapping on the client with some coding
> effort, however this ability does not exist in Cayenne as of now.
>
> Another thing is to make sure that the server is "warmed up" when the
> first client connects, as the server overhead of loading mapping for
> 121000 entities and then converting them to client counterparts may be
> noticeable. So maybe call something like this on server startup:
>
> getDomain().getEntityResolver().getClientEntityResolver()
>
> Andrus
>
>
> On Jun 5, 2009, at 12:35 PM, Zissis Trabaris wrote:
>
>> Here is the scenario ... We have a database with over 121,000 tables
>> mapped in cayenne running under an out of the box ROP client server
>> model. After the client creates the connection, it authenticates the
>> user by querying the user table (that table only currently has
>> about 6
>> rows in it). The initial query always takes about 30 seconds and then
>> everything is fine on subsequent queries. I am wondering if
>> something is
>> going on with the first ROP client query. Is the client trying to
>> cache
>> the server's entity resolver data set?? Or is it something else? Is
>> there any way to speed up the initial client query?
>>
>>
>>
>> Zissis Trabaris * Chief Technology Officer * INSYSWARE * 3235 West
>> River
>> Road, Grand Island, New York, 14072, USA
>> Mobile (716) 930-5654 * Office (518) 636-4118 * Fax (716) 625-1305 *
>> z.trabari..nsysware.com <mailto:%20%20z.trabaris@insysware.com> *
>> www.insysware.com <http://www.insysware.com/>
>>
>> ________________________________
>>
>> CONFIDENTIALITY: This email (including any attachments) may contain
>> confidential, proprietary and privileged information, and
>> unauthorized
>> disclosure or use is prohibited. If you received this email in error,
>> please notify the sender and delete this email from your system.
>> Thank
>> you.
>>
>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Fri Jun 05 2009 - 09:08:47 EDT