Hi,
sorry for reposting but my first mail didn't reach the mailing list. So here are my questions.
I'm using the CometdAdapter as the Adapter class for
grizzly standalone ARP.
In the CometContext
class the blockingNotification can be set to true/false.
With blockingNotification set to true i can get my Test
application up and running.
Grizzly sends
back the correct HTTP header and the answer to my bayeux message in the POST
section.
But with blockingNotification set to false it seems
that Grizzly only sends back the HHTP header
and does not send a POST section at all.
Could someone give me a hint if this is a bug or if i'm doing something
wrong here.
With blockingNotification set to
true, the server blocks for a few seconds after the
notification (at least he seems to block). Using long-polling in my
application i'm doing a reconnect after receiving some data.
If the server is in blocking mode, the reconnect
request does not reach the server and my application hangs.
Any ideas how to avoid this situation without resending the
reconnect request?
Are channels already implemented in grizzly cometd? It seems to be irrelevant to what channel a client subscribed.
When pushing data with something like "channel":"/sample/demo" and a client subsribed to "subscription":"/test/one""
the client gets data for a channel he is not subscribed to.
Thanks for your help
Marco