Clarification : Controlling the Inbound 'Data' messages to bayeux client

[inspire99]

CometD version(s) -- 3.1.3 ( even using later versions such as 7.0.9 )

Java version & vendor -- 1.8

Question:

1. As I understand, Cometd / Bayeux internally uses Jetty HTTP client, to communicate to the BayeuxServer
2. Let's assume the long polling communication is used for inbound 'data' messages to be sent by BayeuxServer in a 'data' channel.
3. Let's assume that the threadpool is configured for Jetty HTTP client. And let's also assume that the thread pool has a limit of 10 threads.
4. Let's assume that, the BayeuxServer has sent a 'data' message and the BayeuxClient downstream is still processing that message.
5. Let's assume that, the BayeuxServer sends 9 more 'data' messages, now, we know that all the 10 threads of Jetty HTTP client is being used and are busy.
6. At this point, can we assume that, though BayeuxServer has few 'data' messages, it cannot possibly send it inbound to BayeuxClient, because the threadpool held by Jetty HTTP Client is fully occupied ?

[sbordet]

1. As I understand, Cometd / Bayeux internally uses Jetty HTTP client, to communicate to the BayeuxServer

That is not correct.

The BayeuxServer is the server-side component of CometD.
It can be accessed by remote clients such as a browser or an HTTP client, or a WebSocket client.

Jetty's HTTP client is not used internally to communicate to the BayeuxServer.
You can use Jetty's HTTP client to remotely to communicate with the BayeuxServer, but it is not used internally, not sure what you mean by that.

4. Let's assume that, the BayeuxServer has sent a 'data' message and the BayeuxClient downstream is still processing that message.
5. Let's assume that, the BayeuxServer sends 9 more 'data' messages, now, we know that all the 10 threads of Jetty HTTP client is being used and are busy.

Let's assume that here you mean a remote BayeuxClient.
What you describe above is not how it works.

Message processing on the client should be quick. If it is not, the client application should spawn a separate thread and perform the lengthy processing on the spawned thread.

The server "pushes" messages to the client typically through only one connection (in reality it's more complicated than this, but only if the client concurrently sends messages to the server, which we can ignore here for sake of explaining in simpler terms).

Therefore the client will only have 1 thread processing the "pushed" messages, and until the client sends another /meta/connect message, the server won't "push" more messages to the client -- they are queued on the server instead.

6. At this point, can we assume that, though BayeuxServer has few 'data' messages, it cannot possibly send it inbound to BayeuxClient, because the threadpool held by Jetty HTTP Client is fully occupied ?

No.

Just run the CometD benchmark with all default values. After a few runs to warm up the JIT, you will see that the BayeuxClient can receive (on my laptop) 80k+ HTTP responses/s with just over 150 threads, far better than what you think 😄