biddyweb / socketio-java Goto Github PK

See GitHub commit 
https://github.com/mathieucarbou/Socket.IO-Java/commit/9d6038af824be18040f091616
2f57df8fa11ea4a

NB: my IDE converted line breaks from windows to unix.

I'm using socketio-java-20101106 and having a issue with Firefox
timing out.

The issue is 100% reproducible with the include ChatServer.
I'm using Jetty 7.1.6, Win7, Java6 1.6.0_16, Firefox 3.6.12.

1) I start the ChatServer and point Firefox at http://localhost:8080/chat.html
2) Type a single message and press Send.
3) Wait.
4) In the Java console I see the expected series of pings, up until
ping 14, at which point I see

IDLE SCEP@13170424      [d=false,io=1,w=true,rb=false,wb=false]
Session[iNgSlINkBB4NZl0yHevy]: sendPing 14
Session[iNgSlINkBB4NZl0yHevy]: sendMessage: [PING]: 14
Session[iNgSlINkBB4NZl0yHevy]: onTimeout
Session[iNgSlINkBB4NZl0yHevy]: onDisconnect: TIMEOUT

After this the client is disconnected. Same thing happens with Opera
11.00 build 1111.
Chrome seems to work well but that's using a different transport so
not that surprising.

I did notice the "IDLE SCEP" line preceded the problem.

Some Googling turned up these (maybe similar ??) issues.
http://jira.codehaus.org/browse/JETTY-1270
http://code.google.com/p/wave-protocol/issues/detail?id=110

Anyone else seeing this or have any ideas on a workaround?
If interested the full logs are posted here.
http://paste.pocoo.org/show/297820/

If you use non western chars like Chinese, Cyrillic, etc with xhr-multipart you 
receive wrong messages with incorrect encoding.

Related issue in WIAB:
https://issues.apache.org/jira/browse/WAVE-187

Attached a patch.

GitHub is a better place to contribute, pull requests, review and clone 
projects. Some scripts exists to export a Mercurial repo into a Git repo.

I've exported to my GitHub Socket.IO Java here:

https://github.com/mathieucarbou/Socket.IO-Java

Since we really need to contribute a lot, an access to the code base in github 
is a requirement for us. So we've migrated the source there. 

We will still send you patched as long as we can but since we will shortly 
convert the project to Maven and split it in several submodules and also 
migrate to Socket.IO's trunk, it will become more difficult for you to merge. 
It is possible also that we make a lot of API changes to better support DI 
frameworks and perhaps also use execution queues to avoid synchronization 
points in the XHRTransport class. Synchronizing a long block of code calling 
listeners is really not recommended and may lead to poor performances. There 
are a lot of good reasons for this described in Effective Java so I won't 
elaborate here ;-)

I think a good way would be that you move the codebase to your github so that 
we can work on a fork. Then it would be easier for you to integrate changes. 
Mercurial has a plugin to work with Git Repos also.

Let me know what you think about all of this !

Thanks,

Mathieu.

I've migrated the clone on GitHub to Maven.

You can see a proposed structure here:

https://github.com/mathieucarbou/Socket.IO-Java

Hello,

it would be good if there was a first steps howto.  I am totally lost on how 
start.

I'm using socketio-java--20101204, Firefox 3.6.12 and Chrome 8.0.552.215

The client sends the server a "test" message.
In response to that message the server does the following.

for (int i = 0; i < 10; i++) {
    outbound.sendMessage(
        SocketIOFrame.JSON_MESSAGE_TYPE,
        JSON.toString(Util.map("say", "Hi " + i)));
}

Sometimes all ten msgs make it to the client.
Most of the time though, only 2 messages are sent to the client and the rest
aren't sent until the client sends a PING.

The long-polling GET request
(http://127.0.0.1:8080/socket.io/xhr-multipart/)

never disconnects or shows any issue.

I added timestamps to the existing server-side logging and this snippet
shows what I'm talking about.

http://paste.pocoo.org/show/301364/

The first 2 lines show 2 messages being sent back to the client, followed by
a 15 second delay, a client PING, and then the rest of the data being sent
to the client.

I'm not able to cause the same problem using the websocket transport in
Chrome.

Hello,


> What steps will reproduce the problem?

Send a large message (around 10 KB) using XHRTransport.


> What is the expected output? What do you see instead?

Transport.sendMessage() should never block for more then a few milliseconds.

TransportBuffer.putMessage tries to acquire a Semaphore and finally times out 
after 5 minutes. It uses the lock count of the semaphore as pointer into the 
buffer, so if the message to be sent is larger than the buffer, it will not be 
able to acquire the semaphore.


> What version of the product are you using? On what operating system?

socket.io-java-20101204.jar on Ubuntu 10.10 and Debian 5.0.8

> Please provide any additional information below.


prio=10 tid=0x00007fe5bc1b5800 nid=0xba8 waiting on condition 
[0x00007fe5c274e000]
java.lang.Thread.State: TIMED_WAITING (parking)
sun.misc.Unsafe.park(Native Method)
parking to wait for  <0x00000000fcfdab80> (a 

java.util.concurrent.Semaphore$NonfairSync)

java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)

java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(Abstr
actQueuedSynchronizer.java:1037)

java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(Abst
ractQueuedSynchronizer.java:1326)

java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:584)

com.glines.socketio.server.transport.TransportBuffer.putMessage(TransportBuffer.
java:123)

com.glines.socketio.server.transport.XHRTransport$XHRSessionHelper.sendMessage(X
HRTransport.java:102)

com.glines.socketio.server.transport.XHRTransport$XHRSessionHelper.sendMessage(X
HRTransport.java:125)






Hendrik

Several libraries (like Google Guice) or containers when embedding are 
requesting an instance of HttpServlet.

=> this patch is for extending HttpServlet instead of GenericServlet so that we 
can bind the Servlet using Google Guice Servlet extension.

NB: see the patch attached. I forgot to disable "optimize imports". You'll see 
the changes are quite little.

Can socketio-java currently be integrated with play framework? Since it's 
servlet based, and play is not, I don't see how this would work.

Also, i would be nice to have socketio-java to work with netty, since play 
works with netty it could make a nice companion to play.

It took me 10 minutes of perusing this site before I noticed the closed issue 
pointing at the new Ovea github location. Please make this obvious on the 
Project Home page to save future visitors some time.