CometD-3 with Tomcat

[John]

Hi Simon,

Since CometD-3 implements websocket transport based on JSR 356. It is not more dependent on Jetty based websockets.

So Would CometD-3 be able to run transparently in Tomcat with Websocket support ?

Are there any issues in running CometD-3 in Tomcat ?

Thanks,

John

[John Bing]

Can someone respond to this ?

--
--
You received this message because you are subscribed to the Google Groups "cometd-users" group.
To post to this group, send email to cometd...@googlegroups.com
To unsubscribe from this group, send email to cometd-users...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cometd-users
 
Visit the CometD website at http://www.cometd.org

---
You received this message because you are subscribed to the Google Groups "cometd-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cometd-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simone Bordet]

Hi,

On Wed, Aug 6, 2014 at 3:20 PM, John Bing <bingj...@gmail.com> wrote:
> Can someone respond to this ?

Easy, I'll be looking at this later today, modulo some work on HTTP/2
that I have to finish.

Have you tried already ? Or you were just asking ?

--
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.

[John Bing]

Sure..

I have not tried this because I have seen lot of posts not to run CometD in tomcat. CometD with tomcat is buggy and not scalable.

That's why I want to ask you first, that does it still has issues like websockets or like tomcat with CometD is buggy specially under load ?

John

[John_Backster]

Hey.
Cometd with Tomcat 7 works fine when using just longpolling. Tomcat 8 with cometd doesn't work because tomcat has enabled the nio connector as a default in version 8. Cometd randomly throws errors if you use nio.
Tomcat (7 or 8) wit cometd and websockets doesn't work.

Problem is, cometd is beeing developed by jetty guys. Therefore on jetty everything works great. Tomcat has the limitations mentioned above..

[Simone Bordet]

Hi,

On Wed, Aug 6, 2014 at 6:34 PM, John_Backster <chriz...@gmail.com> wrote:
> Hey.
> Cometd with Tomcat 7 works fine when using just longpolling. Tomcat 8 with cometd doesn't work because tomcat has enabled the nio connector as a default in version 8. Cometd randomly throws errors if you use nio.
> Tomcat (7 or 8) wit cometd and websockets doesn't work.

I just tried the CometD demo version 3.0.1-SNAPSHOT with Tomcat 8.0.9.
Short story: WebSocket works fine, HTTP no.

Long story:
CometD 3 has been modified to avoid concurrent async writes, which are
allowed by the specification but that Tomcat rejects.
This was the initial showstopper that Christian refers to as "randomly
throws errors", and it's been fixed.
WebSocket via JSR 356 works fine in Tomcat, as long as batched writes
are disabled.
Batched writes are a feature of WebSocket that under Jetty showed a
bit better performance than without.
Unfortunately it's broken in Tomcat: I have a network trace that shows
how Tomcat writes in a loop empty WebSocket frames until the browser
kills the connection.
With batched writes disabled, Tomcat works fine.

HTTP in CometD 3.0 has been enhanced to take advantage of Servlet 3.1 Async I/O.
There are 2 problems here. The first is that CometD uses the Servlet
API in a way that is illegal, but that Jetty forgives, while Tomcat
does not.
This is clearly a CometD bug that I have already fixed in master.
The second problem is that CometD autodetects whether it's been
deployed in a Servlet 3.1 container. If so, it uses the async I/O HTTP
transport, otherwise it sticks with the normal, Servlet 3.0 transport.
Even with the API problem fixed, Tomcat's async I/O is broken: it
seems that reads are woken up only after 10s, while it works fine in
Jetty where reads are performed immediately.
I need to investigate more this issue.

So, expect a CometD 3.0.1 release soon with better defaults (batched
writes disabled for WebSocket, and perhaps Servlet 3.0 HTTP
transport), the Servlet API bug fixed.
With this configuration, Tomcat and Jetty will just work.

[John_Backster]

Simone, if websockets plus longpolling in tomcat 8 would work, it would be one awesome day for us.

I will wait with upgrading until cometd 3.01 is out. (I assume with just saying http you mean longpolling?)

[Simone Bordet]

Hi,

On Wed, Aug 6, 2014 at 9:39 PM, John_Backster <chriz...@gmail.com> wrote:
> Simone, if websockets plus longpolling in tomcat 8 would work, it would be one awesome day for us.

When I say "works" it means that basic functionality of the CometD
demo works as expected without exceptions or errors.
From there to say that scales as well as Jetty under load, or under
bad network conditions, I don't know :)
I know Jetty scales because we run load tests every release, but I
don't have any information about how Tomcat would work under load.

> I will wait with upgrading until cometd 3.01 is out. (I assume with just saying http you mean longpolling?)

Yes, HTTP means the long-polling transport.

[Simone Bordet]

Hi,

On Wed, Aug 6, 2014 at 9:43 PM, Simone Bordet <sbo...@intalio.com> wrote:
> Hi,
>
> On Wed, Aug 6, 2014 at 9:39 PM, John_Backster <chriz...@gmail.com> wrote:
>> Simone, if websockets plus longpolling in tomcat 8 would work, it would be one awesome day for us.
>
> When I say "works" it means that basic functionality of the CometD
> demo works as expected without exceptions or errors.
> From there to say that scales as well as Jetty under load, or under
> bad network conditions, I don't know :)
> I know Jetty scales because we run load tests every release, but I
> don't have any information about how Tomcat would work under load.

While prepping 3.0.1 I retested Tomcat 8, and HTTP is definitely a no
go, even with the Servlet 3.0 transport (but also the Servlet 3.1 has
problems).
For some reason, Tomcat 8 does not react to a simple dispatch() call.
It's definitely a Tomcat bug.
I tried on 7.0.55 and the Servlet 3.0 transport "works", although I
did not test in detail.

At this point, I am - again - strongly suggesting people to use Jetty.
The combo Jetty + CometD is much better tested, much more reliable,
and has commercial support.

While CometD uses standard APIs, the implementation of those API
provided by servlet container differ, and at the end that is what
matters.
If you want to stick with Tomcat, be prepared to fight.

[Brent Bahry]

Is CometD 2 + Tomcat any more stable?

[Anuj]

Hey Simon,

As you specified :

"For some reason, Tomcat 8 does not react to a simple dispatch() call. It's definitely a Tomcat bug. "

Can you specify somewhere if it is reported ? or any workaround for this ?

Thanks,
Anuj

[Simone Bordet]

Hi,

On Tue, Aug 12, 2014 at 5:31 PM, Anuj <khandelw...@gmail.com> wrote:
> Hey Simon,
>
> As you specified :
>
> "For some reason, Tomcat 8 does not react to a simple dispatch() call. It's
> definitely a Tomcat bug. "
> Can you specify somewhere if it is reported ? or any workaround for this ?

I don't know if it is reported, I doubt there is a workaround for this
core functionality.

[Simone Bordet]

Hi,

On Tue, Aug 12, 2014 at 5:31 PM, Brent Bahry <brent...@gmail.com> wrote:
> Is CometD 2 + Tomcat any more stable?

CometD 2 on Jetty is stable.
CometD 3 on Jetty is stable.

I don't know what to say, really... perhaps Jetty is much more tested
on its async features.

It's not really matter of CometD 2 + Tomcat or CometD 3 + Tomcat: it's
not CometD the problem.

[Anuj]

Hi Simon,

I understand that it's not the problem with CometD.
A little favor. Since you have the detailed understanding to the dispatch() call bug. Can you raise a tomcat ticket for this bug in Tomcat.

Thanks,
Anuj

[Anuj]

For some reason, Tomcat 8 does not react to a simple dispatch() call.
It's definitely a Tomcat bug.
I tried on 7.0.55 and the Servlet 3.0 transport "works", although I
did not test in detail.

I was going through the CometD source code and found below comment in AbstractStreamHttpTransport.java :
----------------
            // We dispatch() when either we are suspended or timed out, instead of doing a write() + complete().
            // If we have to write a message to 10 clients, and the first client write() blocks, then we would
            // be delaying the other 9 clients.
            // By always calling dispatch() we allow each write to be on its own thread, and it may block without
            // affecting other writes.
            // Only with Servlet 3.1 and standard asynchronous I/O we would be able to do write() + complete()
            // without blocking, and it will be much more efficient because there is no thread dispatching and
            // there will be more mechanical sympathy.
----------------

As you mentioned that tomcat-8 does not react to dispatch() call. Since Tomcat-8 is servlet -3.1 compliant and has standard async I/O,; We should we use write() + complete() instaed of dispatch() as specified in comment.. Will it solve our problem ?

Thanks,
Anuj 

[Anuj]

In addition, :
From https://docs.oracle.com/javaee/6/api/javax/servlet/AsyncContext.html#dispatch()

""If this method is called before the container-initiated dispatch that called startAsync has returned to the container, the dispatch operation will be delayed until after the container-initiated dispatch has returned to the container.""

Is this causing the delay in reading the messages (~10sec) ?


Thanks,
Anuj

[Simone Bordet]

Hi,

On Thu, Nov 27, 2014 at 8:29 AM, Anuj <khandelw...@gmail.com> wrote:
> I was going through the CometD source code and found below comment in
> AbstractStreamHttpTransport.java :
> ----------------
> // We dispatch() when either we are suspended or timed out,
> instead of doing a write() + complete().
> // If we have to write a message to 10 clients, and the first
> client write() blocks, then we would
> // be delaying the other 9 clients.
> // By always calling dispatch() we allow each write to be on its
> own thread, and it may block without
> // affecting other writes.
> // Only with Servlet 3.1 and standard asynchronous I/O we would
> be able to do write() + complete()
> // without blocking, and it will be much more efficient because
> there is no thread dispatching and
> // there will be more mechanical sympathy.
> ----------------
>
> As you mentioned that tomcat-8 does not react to dispatch() call. Since
> Tomcat-8 is servlet -3.1 compliant and has standard async I/O,; We should we
> use write() + complete() instaed of dispatch() as specified in comment..
> Will it solve our problem ?

This transport will not be used for Servlet 3.1 containers by default,
so it should be left as is.
Any compliant non-buggy implementation will be able to run CometD as
is, without any change.

[Simone Bordet]

Hi,

No.