about jetty dependencies - #5

I've deployed cometd (which uses jetty continuations) into Tomcat 6.0.27. Because Tomcat 6 doesn't support Servlet 3.0 ContinuationsSupport returns an instance of the FauxContinuation which isn't asynchronous. I don't remember which jetty jars I had to include to make it work.

Now that I've had a chance to take a brief look at Atmosphere, I'm wondering if it wouldn't make more sense to just add Socket.IO support to Atmosphere instead of rolling our own multi-container support. Is there something about Atmosphere that would preclude it from use?

Hi,
Atmosphere does not have any client side library supporting several cell phones, and it is a very complicated project with a maven structure that should be re-worked. We are using jetty on server side so jetty does not bring anything for us compared to socketio.
When we deployed the war file with socket io in it, it failed because jetty does not allow access to jetty server classes from a webapp. You have to add exclusions. So this change just enables to not depend on jetty classes.

I was wondering how you deploy your webapp. I think we do not deploy them as you do. In our war file, we only have socket-io-java: we do not have any jetty jar.

By reading you, i understand that you have in your war file socket-io-java + jetty-websocket + jetty-continuations + some other libraries ? Is it true ?

Thanks,

Mathieu.

Regarding deployment of Socket.IO-Java, in a jetty container only the socketio-java jar is needed in the war. In a non-jetty servlet 3.0 container, some jetty jars are needed in the war file. Continuations can also be used in a non-jetty, non-servlet 3.0 container, but it will consume one thread poer request (clearly non-optimal).

The only live deployment of Socket.IO-Java I have experience with is in the Wave in a Box project where jetty is embedded in the application, so deployment is programatic. However, CometD also uses jetty continuations and I have deployed that into Tomcat 6.0.27.

If you want to support Socket.IO in many servlet containers then the question that needs to be answered is: Do you want to support non-jetty, non-servlet 3.0 containers. If you do, then taking advantage of the work already done in Atmosphere seems logical. I see no reason to re-invent the wheel. If Atmosphere doesn't allow use of just the core async/websocket API overlay piece, then perhaps a patch to that project would be better.

Hi,
Thank you for your reply. This is why you didn't see the error: deploying socketio java in a war is not sufficient. In a programmatic startup of jetty, it works. But when deployed on a jetty container distribution, there is a classpath separation between jetty server classes: the webapp does not see them. So the ConnectionTimeoutPreventer class is not working.
I agree with you that if we need to get support for multiple containers, the Atmosphere project is better. But this is not a requirement for us.

Ah, I'd forgotten about that class. The only reason I created that class was because I didn't like the idea of setting maxidletime to 0 for the SelectChannelConnector. You can see the details of the problem here: http://code.google.com/p/socketio-java/issues/detail?id=1

The xhr-multipart and htmlfile transports are not jetty specific, but they do currently use the ConnectionTimeoutPreventer. The best thing to do would be to modify that class so that in the case of a non-embedded deployment, it returns a fake/dummy IdleCheck instance.

Ok. So you can take the new implementation i've made: it uses reflection to reduce the number of exclusions to add to the jetty context file. Only the HttpConnection class is needed.
So it just miss the check to return a dumy implementation instead of trying to call the method reflectively.

Just another question: we've seen today that on android 2.1 and 2.2 socket-io switches to xhr-polling. I was wondering why it does not use instead xhr-multipart.

Also, when you say that xhr-multipart and htmlfile are not jetty specific, it is also the case for the others, except for websocket, isn't it ?

Tad,
I love the direction Mathieu has taken with his fork. Do you ever have plans on handling his pull request?

As I see it, there are four major implementations forks now. 1) code.google project 2) your github repo 3) mathieu's fork 4) scalatra fork (scalatra is a rapidly growing new web framework).

I am looking at creating a grails plugin for socket.io. I was hoping to include the socketio-java project as a dependency. Right now, I have the following concerns:

1. A release jar has never been added to a central maven/ivy repo. (Needed by maven, ivy, sbt, gradle, etc.. build tools).
2. The current major contributor's (mathieu) changes aren't being merged into the trunk/head of the creator's repo.

At this point i'm likely going to base my new project off of meathieu's fork, as it seems to be maintained unlike yours.

Hi,

Socket.IO Java from Tad is initially a Java port used in Apache Wave I think, but it is stuck to an old version of the Socket.IO javascript library and they used to deploy it in an application starting an embedded Jetty. So they do not had separate classloaders.

I tried to refactor this so that it can work better in a standard jetty container, plus also being able to support much more servers and also I wanted to upgrade the Javascript library.

But we stopped the efforts on Socket.IO because of several issues we had:

• complicated / poor error handling
• connection delay too long
• missing features
• not so stable as we would like

We first chose it because it supported WebSocket, but from now, CometD, which is a far more reliable solution, also supports WebSockets since version 2 (release at the beginning of this year). So we moved our efforts and we contribute much more to the CometD library which meets our requirements: reverse-ajax on desktop and mobile on all browsers. Also CometD supports less transports (mainly http long polling and websockets) because the other ones have some flaws. I.e. HTTP Streaming is subject to buffering issues which can cause some high latency.

I created this project initially as a quick and dirty way to get Wave to work in browsers that didn't have native support of WebSockets. I had initially considered using CometD but chose to to create this instead because it would result in the smallest modification to the Wave code. I now regret that decision. I recommend that you look at the CometD and Atmosphere projects instead. They have broader support and usage (much more int he case of CometD).