Quantcast
Channel: SmartClient Forums
Viewing all articles
Browse latest Browse all 4756

RPCManager.startQueue() processing order

$
0
0
Hi Isomorphic,

I'm using current 4.1p (v9.1p_2014-12-06).

Are the client-side requests added in a
Code:

RPCManager.startQueue()
...some requests...
RPCManager.sendQueue();

flow guaranteed to be executed in the same order as added on the client side? Can this change due to parallel execution / connection pooling on the server side?

In the server logs I notice entries (shortened) like
Code:

=== 2014-12-09 14:07:30,218 [c-32] INFO  Compressi
=== 2014-12-09 14:07:31,180 [c-11] INFO  DSRespons
=== 2014-12-09 14:07:31,181 [c-11] DEBUG RPCManage
=== 2014-12-09 14:07:31,181 [c-11] DEBUG SQLTransa
=== 2014-12-09 14:07:31,182 [c-11] DEBUG RPCManage
=== 2014-12-09 14:07:31,183 [c-11] DEBUG SQLTransa
=== 2014-12-09 14:07:31,183 [c-11] DEBUG SQLTransa
=== 2014-12-09 14:07:31,184 [c-11] DEBUG SQLConnec
=== 2014-12-09 14:07:31,185 [c-11] INFO  Compressi
=== 2014-12-09 14:07:32,150 [ec-5] INFO  DSRespons
=== 2014-12-09 14:07:32,151 [ec-5] DEBUG RPCManage
=== 2014-12-09 14:07:32,151 [ec-5] DEBUG SQLTransa
=== 2014-12-09 14:07:32,152 [ec-5] DEBUG RPCManage
=== 2014-12-09 14:07:32,153 [ec-5] DEBUG SQLTransa
=== 2014-12-09 14:07:32,153 [ec-5] DEBUG SQLTransa
=== 2014-12-09 14:07:32,153 [ec-5] DEBUG SQLConnec
=== 2014-12-09 14:07:32,155 [ec-5] INFO  Compressi
=== 2014-12-09 14:09:48,028 [c-39]

where the [c-32], [c-11], [ec-5], [c-39] should be thread names (log4j conversion pattern "<param name="ConversionPattern" value="=== %d [%.4t] %-5p %c{1} - %m%n" />").

Currently I'm executing 3 different updates in a queue, all of them can result in a different result for another fetch.
Right now I'm doing this fetch in the CallBack of every successful request (=3x the same fetch), where one fetch after the last request would be enough.

If they are guaranteed to be executed in order I could just add the fetch to the queue (instead of doing it in a DSCallBack). If not, I'd need some other mechanism on the client (most likely a RPCQueueCallback(?)).

Best regards,
Blama

Viewing all articles
Browse latest Browse all 4756

Trending Articles