Is order of AMF requests ensured?

[mar...@flexets.com]

Hi,
I guess there may be a problem of ensuring the order of rapidly produced AMF requests, when travel via more TCP connections.
Is the order of requests produced by GraniteDS client ensured?
Or a workaround: 
Is there a way to limit the number of connections used by GraniteDS client to 1?

Thank you
Martin

[Kris Hofmans]

Granite calls are bundled, in order, executed in order, so you can have 1 button that does 3 remote calls:

.create(personWithId1)

.delete(personWithId1) 

and it will first call the create and only then the delete, which will then be successful

--

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Granite Data Services Forum".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse graniteds+...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Martin Tuzinsky]

Kris, Thank you for your answer. However I am still not clear if in-order AMF call processing is ensured by a GraniteDS channel regardless if the client side application layer code waits for each ack response (sync) or if the client application can send-ahead multiple requests (async) without waiting for any response, and trust that the server will always receive requests in order.

In BlazeDS using HTTP it looks like there is a something like a TCP connection pool which creates another connection if an existing TCP stream is busy.  The same for a streaming or non-streaming BlazeDS channel. This is a huge problem if trying to achieve in-order call processing on the server side.

So can you (or anyone) share some insight into GraniteDS usage of underlying TCP connections. Specifically the number of TCP connection streams in use at the same time by a single client, and does a GraniteDS stream remain connected for the life of a channel?

Thank you
Martin

[Lasha K]

Hi, Martin.
I assume that you are talking about GravityChannel which is used for Push messages and also internal GraniteDS information transfers via this type of channel.
As far as I see during my work with GraniteDS. There are at least 3 operations that will be always sent via this channel.
1. Granite will send Ping operation to ensure that server is reachable.
2. Granite will send Subscribe operation which will subscribe client to the particular node (if it is in a cluster).
3. Granite will send Connect operation. The http request for this operation will be opened until there are some pending messages except Connect operation.
As far as I see this request is using async mechanisms and if your APP server doesn't support Servlet3 - you will be facing some issues. For example, if this request fail by timeout - then you will have to relogin when you client reaches @PreAutorise method.
At this point I haven't seen any multiple async requests.
Here is what I see in my working app. It uses GraniteDS and JMS Push mechanism. It is all working on Weblogic 12c. Pending http request - is Connect Operation about which I was talking. Hope I spread some light on your question..