[Client Side JS] Scheduler not working randomly when cometd object is reconfigured at runtime. about cometd HOT 12 CLOSED

Hello, @sbordet ,

I've found the issue on why the scheduler was not working. Turns out it was not to CometD, it was due to one of my actions. Apologies for the confusion 🙂. Appreciate the time you put into this one. Thanks much.

from cometd.

CometD 3.1.x is now at end of life, as well as CometD 4.0.x, and CometD 5.0.x is at End of Community Support (see #1179).

Would you be able to upgrade to CometD 7.0.x and verify if the problem still happens?
If you use the client-side JavaScript library only, there should not be many differences from 3.1.x and 7.0.x.

from cometd.

@shrihari-prakash I need for information about what you exactly mean by:

when cometd is reconfigured with different URL at runtime

We know that the default scheduler (that attached to the window object) is throttled by browsers, so we have implemented a scheduler that runs on a Worker, which is used by default.

Do you have evidence that the Worker scheduler is also throttled?

from cometd.

Hello @sbordet ,

Here's what I mean when I say "reconfigure":

1. Call cometd.configure({ url: 'http://host/cometd' });
2. After a while disconnect the cometd and call cometd.configure({ url: 'http://**host2**/cometd' });
3. Now after handshake, the scheduler randomly stops working (ie, the timeout for sending /connect does not execute.

I do not mean to say that the scheduler is being throttled. I suspect when the cometd scheduler methods (like setTimeout) are re-initialized the second time in cometd client code (ie, step 2 of the above scenario), there is a problem where the setTimeout callback for sending connect request is not executed.

In the above scenario I tried putting some logs just before the timeout is called and inside the callback. And I ended up seeing only the log where the setTimeout was called triggered.

cc: @aure-olivier

from cometd.

@shrihari-prakash are you using the Worker scheduler? Or the window scheduler?

Seems weird to me that there would be a "random" problem -- from what you describe it would look like a JavaScript bug.
What browser shows this behavior?

Re-instantiating the scheduler is not a problem, but I would like to understand this issue in more detail before trying out speculative changes.

from cometd.

@shrihari-prakash also, let us know if you're willing to upgrade to CometD 7.0.x.

It brings two main features: more modern JavaScript, and TypeScript type definitions in case you're using TypeScript.
Also, it is currently maintained while 3.1.x is at end-of-life and currently abandoned.

As Webtide customer, we can "resurrect" and update CometD 3.1.x for you, but we recommend that you upgrade to CometD 7.0.x instead -- as I said it should be a drop-in dependency update.

The advantage is that you will be up-to-date and kill the technical debt with our help, since we can help you migrate in case there are issues in the upgrade.

from cometd.

@shrihari-prakash also, let us know if you're willing to upgrade to CometD 7.0.x.

It brings two main features: more modern JavaScript, and TypeScript type definitions in case you're using TypeScript.

Also, it is currently maintained while 3.1.x is at end-of-life and currently abandoned.

As Webtide customer, we can "resurrect" and update CometD 3.1.x for you, but we recommend that you upgrade to CometD 7.0.x instead -- as I said it should be a drop-in dependency update.

The advantage is that you will be up-to-date and kill the technical debt with our help, since we can help you migrate in case there are issues in the upgrade.

Hi Simone!

Unfortunately we upgraded to v7 recently and it was working fine, except for IE11 browser which does lot support modern JavaScript instructions ... so we were forced to rollback. IE11 is very old browser and will be out of support at Genesys side soon, but for the moment this is not the case so upgrading to v7 is not an option for the moment.

from cometd.

Hello @sbordet ,

1. I am using the worker scheduler. Although, disabling the worker scheduler also fixes the problem, but it is not recommended due to throttling.
2. I am noticing that the issue happens on Chrome and Edge Chromium. Works fine with Firefox.
3. As Aurelien pointed out, we are unfortunately unable to upgrade to 7.x due to incompatibilities with IE.

from cometd.

@aure-olivier, then at least you can upgrade to CometD 5.0.x, as it still has the old JavaScript syntax?
It will reduce the debt (easier upgrade to CometD 7 or CometD 8 in the future), and we can more easily do a release for 5.0.x.

Do you have more details about when the issue happens?
Do you have the browser tab idle since a long time?
Is the browser tab in background?

from cometd.

Thans @sbordet ,
I checked the latest 5.0.14 version, and it seems fine.
We will likely upgrade to version 5 soon.

For other questions, I'll let @shrihari-prakash answer.

Regards,
Aurélien.

from cometd.

Hi, @sbordet ,
The issue happens when configure function is called the second time (or sometimes second one succeeds, but third time fails). The handshake actually succeeds, and nothing happens next. The browser is well active and running in foreground while this happens.

from cometd.

@shrihari-prakash do you have logging at DEBUG level when this happens?

Can you reproduce the issue?
I ask because there is not much for us to understand the issue, and your proposed fix (reallocate the scheduler in configure()) should not be necessary at all, so I am a bit reluctant to add speculative changes.

from cometd.