dojo client to send async meta/connect
17 views
Skip to first unread message
Ram C
Aug 30, 2019, 9:16:17 PM8/30/19
to cometd-users
Hi,
I look at the forum and found similar issue and the reply on that.
On Thu, Apr 27, 2017 at 6:00 PM, pradeep bansal <bprad...@gmail.com> wrote:
> Hi,
>
> I am receiving following stack trace on my firefox browser when connecting
> using long polling.
>
> Can you please help me debugging this. Please note its working fine in IE
> and chrome.
>
> 21:09:54.330 Exception during execution of listener Object { id: 3, channel:
> "/meta/unsuccessful", scope: undefined, callback: _metaUnsuccessful(),
> listener: true } Object { channel: "/meta/subscribe", id: "2", error:
> "402::Unknown client", successful: false } TypeError: message.request is
> undefined
You have an error in cometd.init.js, which is your code, not CometD's.
The error you get from the server, 402::Unknown client, means that the
server timed out the session because the client did not send the
required /meta/connect message.
This happens when the client connection is broken, or when the client
performs too long computations that blocks the CometD processing.
> Hi,
>
> I am receiving following stack trace on my firefox browser when connecting
> using long polling.
>
> Can you please help me debugging this. Please note its working fine in IE
> and chrome.
>
> 21:09:54.330 Exception during execution of listener Object { id: 3, channel:
> "/meta/unsuccessful", scope: undefined, callback: _metaUnsuccessful(),
> listener: true } Object { channel: "/meta/subscribe", id: "2", error:
> "402::Unknown client", successful: false } TypeError: message.request is
> undefined
You have an error in cometd.init.js, which is your code, not CometD's.
The error you get from the server, 402::Unknown client, means that the
server timed out the session because the client did not send the
required /meta/connect message.
This happens when the client connection is broken, or when the client
performs too long computations that blocks the CometD processing.
when the message has lot of data my app takes long compute time and results in exact above behavior. Then it reconnects, resubscribes to get future messages. I'm losing the message that happens during this compute time (sometimes it is more than the maxInterval (30sec) time result in server timeout/cleanup).
Is there a way to asynchronously handle this long compute and not to block the CometD processing? I used setTimeout to handle the data in my subscribe callback but that doesn't help. the subsequent meta/connect request made after the long compute.
thanks,
Ram
Simone Bordet
Sep 2, 2019, 3:02:02 AM9/2/19
to cometd-users
Hi,
On Sat, Aug 31, 2019 at 3:16 AM Ram C <time...@gmail.com> wrote:
> when the message has lot of data my app takes long compute time and results in exact above behavior.
> Then it reconnects, resubscribes to get future messages. I'm losing the message that happens during this compute time (sometimes it is more than the maxInterval (30sec) time result in server timeout/cleanup).
You have a problem in your application if it takes you 30+ seconds to
process data. You can't leave a browser frozen for that long, the
users will just close the browser and retry.
You should move to processing the data asynchronously so that CometD
(and any other UI activity) does not get blocked and the user can
still interact with the UI.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
On Sat, Aug 31, 2019 at 3:16 AM Ram C <time...@gmail.com> wrote:
> when the message has lot of data my app takes long compute time and results in exact above behavior.
> Then it reconnects, resubscribes to get future messages. I'm losing the message that happens during this compute time (sometimes it is more than the maxInterval (30sec) time result in server timeout/cleanup).
process data. You can't leave a browser frozen for that long, the
users will just close the browser and retry.
You should move to processing the data asynchronously so that CometD
(and any other UI activity) does not get blocked and the user can
still interact with the UI.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Ram C
Sep 2, 2019, 9:30:13 AM9/2/19
to cometd-users
Hi Simone,
I get a message with around 350 event messages merged in a single packet. Then cometd.js calls the subscribe call back for each event message, in the callback I call setTimeout(handleEvent, 0). I expect the setTimeout adds task to the queue and returns immediately then subscribe callback returns. And the cometd.js should continue its long poll operation. But what I observed (in Firefox) is the setTimeout returns immediately, subscribe callback returns, all the tasks in timeout queue get processed and finally the cometd is making new long poll connection. Not sure why the tasks are executed first. If subscribe callback returns then comet.js continue its long poll operation, correct?
Is there a way to limit the number of messages sent to the client? If I set maxQueue=<small number> will that avoid merging all messages in the Queue<ServerMessage>?
Increasing the maxInterval helps here?
thanks,
Ram
Hi,
Simone Bordet
Sep 2, 2019, 12:08:40 PM9/2/19
to cometd-users
Hi,
On Mon, Sep 2, 2019 at 3:30 PM Ram C <time...@gmail.com> wrote:
>
> Hi Simone,
>
> I get a message with around 350 event messages merged in a single packet.
You have not explained what your application is about, but I challenge
any human to look at 350 different things in a UI in less than 350
seconds, which is 6 minutes.
The fact that your server side system produces 350 events in a short
period of time does not mean you have to relay all of them.
For example, if these events are stock price changes, you only need to
deliver the final price, say once every second.
> Then cometd.js calls the subscribe call back for each event message, in the callback I call setTimeout(handleEvent, 0). I expect the setTimeout adds task to the queue and returns immediately then subscribe callback returns.
Yes, so now you have 350 events in the JavaScript engine queue.
After all of those, CometD queues the /meta/connect message, so it is
being delayed by your application to process the 350 events.
JavaScript is single threaded and CometD cannot send back a
/meta/connect before all messages are processed (otherwise the client
must perform infinite buffering).
> Is there a way to limit the number of messages sent to the client?
Yes, you don't send them in the first place.
This is entirely application dependent - you have to implement the
logic that decides whether a message should or should not be sent.
You may do this less efficiently by using a
ServerSession.DeQueueListener, where you navigate the queue of
messages and discard those that should not be sent.
> If I set maxQueue=<small number> will that avoid merging all messages in the Queue<ServerMessage>?
No, a small maxQueue will just drop messages without any logic.
> Increasing the maxInterval helps here?
I don't think so.
I think you have a fundamental flaw in your application if you need to
deliver 350 messages at once.
On Mon, Sep 2, 2019 at 3:30 PM Ram C <time...@gmail.com> wrote:
>
> Hi Simone,
>
> I get a message with around 350 event messages merged in a single packet.
any human to look at 350 different things in a UI in less than 350
seconds, which is 6 minutes.
The fact that your server side system produces 350 events in a short
period of time does not mean you have to relay all of them.
For example, if these events are stock price changes, you only need to
deliver the final price, say once every second.
> Then cometd.js calls the subscribe call back for each event message, in the callback I call setTimeout(handleEvent, 0). I expect the setTimeout adds task to the queue and returns immediately then subscribe callback returns.
After all of those, CometD queues the /meta/connect message, so it is
being delayed by your application to process the 350 events.
JavaScript is single threaded and CometD cannot send back a
/meta/connect before all messages are processed (otherwise the client
must perform infinite buffering).
> Is there a way to limit the number of messages sent to the client?
This is entirely application dependent - you have to implement the
logic that decides whether a message should or should not be sent.
You may do this less efficiently by using a
ServerSession.DeQueueListener, where you navigate the queue of
messages and discard those that should not be sent.
> If I set maxQueue=<small number> will that avoid merging all messages in the Queue<ServerMessage>?
> Increasing the maxInterval helps here?
I think you have a fundamental flaw in your application if you need to
deliver 350 messages at once.
Ram C
Sep 2, 2019, 12:28:52 PM9/2/19
to cometd-users
Hi Simone,
thanks for the detailed reply. This is the call center monitor application where we get events for the active calls. there could be multiple events happening for a single call for ex multiple persons joined/dropped.
User of this app has the ability to choose one of the random call to work on. there could be multiple users at the same time looking at particular call or any random call.
Is there a parameter in the server side to avoid merging of all those events? send 20 events at one time?
thanks,
Ram
On Monday, September 2, 2019 at 12:08:40 PM UTC-4, Simone Bordet wrote:
Hi,
Simone Bordet
Sep 2, 2019, 5:12:39 PM9/2/19
to cometd-users
Hi,
On Mon, Sep 2, 2019 at 6:28 PM Ram C <time...@gmail.com> wrote:
>
> Hi Simone,
>
> thanks for the detailed reply. This is the call center monitor application where we get events for the active calls. there could be multiple events happening for a single call for ex multiple persons joined/dropped.
>
> User of this app has the ability to choose one of the random call to work on. there could be multiple users at the same time looking at particular call or any random call.
Still, I doubt a single human user can process 350 different changes in the UI.
Without knowing the exact details, it's difficult to help you.
There are a million ways to fix this issue, from a redesign of the
client application to only show relevant information (and not the
entirety of changes that the server pushes to the client), to the
redesign of the server application to only send relevant information
to the client.
If you can prioritize your messages, you can do something like this:
for every message you look at the priority, let's say it's 0 for
highest and 10 for lowest, and you schedule the message processing
priority milliseconds later.
This is easy with setTimeout(handleEvent, message.priority).
Hopefully, in this way you have few 0 priority messages which will
compete with CometD's /meta/connect, and all the other messages will
be processed 1+ milliseconds later.
Of course the processing will take time, so eventually the processing
of higher priority messages will delay the processing of lower
priority messages, and at that point you may have ordering issues when
the next batch of messages arrive.
> Is there a parameter in the server side to avoid merging of all those events? send 20 events at one time?
I don't think this is helping you?
After a few roundtrips, your server may need infinite buffering.
The more I think about this problem the more I think it's a mistake to
send to the client these many messages.
On Mon, Sep 2, 2019 at 6:28 PM Ram C <time...@gmail.com> wrote:
>
> Hi Simone,
>
> thanks for the detailed reply. This is the call center monitor application where we get events for the active calls. there could be multiple events happening for a single call for ex multiple persons joined/dropped.
>
> User of this app has the ability to choose one of the random call to work on. there could be multiple users at the same time looking at particular call or any random call.
Without knowing the exact details, it's difficult to help you.
There are a million ways to fix this issue, from a redesign of the
client application to only show relevant information (and not the
entirety of changes that the server pushes to the client), to the
redesign of the server application to only send relevant information
to the client.
If you can prioritize your messages, you can do something like this:
for every message you look at the priority, let's say it's 0 for
highest and 10 for lowest, and you schedule the message processing
priority milliseconds later.
This is easy with setTimeout(handleEvent, message.priority).
Hopefully, in this way you have few 0 priority messages which will
compete with CometD's /meta/connect, and all the other messages will
be processed 1+ milliseconds later.
Of course the processing will take time, so eventually the processing
of higher priority messages will delay the processing of lower
priority messages, and at that point you may have ordering issues when
the next batch of messages arrive.
> Is there a parameter in the server side to avoid merging of all those events? send 20 events at one time?
After a few roundtrips, your server may need infinite buffering.
The more I think about this problem the more I think it's a mistake to
send to the client these many messages.
Ram C
Sep 4, 2019, 9:53:08 AM9/4/19
to cometd-users
Hi Simone,
I was thinking about prioritize the events but later realized the ordering of messages is more important. I agree the app needs to be redesigned with what the user is interested rather dumping all events happening at server side.
your responses are very helpful. Thanks a lot.
Ram
On Monday, September 2, 2019 at 5:12:39 PM UTC-4, Simone Bordet wrote:
Hi,
Reply all
Reply to author
Forward
0 new messages