SocketWrapper.checkConnection

[timfox]

Hi-

I noticed that checkConnection is called immediately before any invocation is made.

This seems to write a byte to the socket outputstream then flushes it. If the invocation itself is small enough to fit in one tcp packet then does this mean we are effectively sending a minimum of two packets per invocation?

Apologies in advance if I have the wrong end of the stick on this one.

[timfox]

The reason I mention this is that it seems to be giving us an approx. 30% performance degradation in JBossMessaging.

When I disable connection checking in my local copy of remoting I get this 30% back.

[tom.elrod]

The reason for sending this byte for the socket invoker is to keep the socket connection open between the client and server. After each request on the server side, it will send an ACK byte to the client. After each client call, the socket will be pooled and if this socket is pulled out of the pool before the timeout value, it will send the an ACK back to the server (in the checkConnection()) and then make the request. The whole point is to keep the socket connection open if going to be reusing it within a short amount of time (as the ACK is much faster than creating a whole new socket from scratch).

I can see where if going to make continous calls back to back on the same connection, then this would add overhead. Is this for a real use case, or for perforamnce testing where want to see max throughput?

Guess we can add a configuration so the ACK is turned off. If you think this is needed, please open a jira issue for it.

Also, we probably need to discuss what remoting jira issues you need and when. The next release in jira is for 1.6.0, but I doubt that will be till this summer. If you need some of these issuses resolved before then, we may need to add a 1.4.1 release with an earlier release date.

[timfox]

The reason for sending this byte for the socket invoker is to keep the socket connection open between the client and server. After each request on the server side, it will send an ACK byte to the client. After each client call, the socket will be pooled and if this socket is pulled out of the pool before the timeout value, it will send the an ACK back to the server (in the checkConnection()) and then make the request. The whole point is to keep the socket connection open if going to be reusing it within a short amount of time (as the ACK is much faster than creating a whole new socket from scratch).

I can see where if going to make continous calls back to back on the same connection, then this would add overhead. Is this for a real use case, or for perforamnce testing where want to see max throughput?

This is for the use case where many messages are sent in quick succesion to the server

Guess we can add a configuration so the ACK is turned off.

Yes please

If you think this is needed, please open a jira issue for it.

Will do

Also, we probably need to discuss what remoting jira issues you need and when. The next release in jira is for 1.6.0, but I doubt that will be till this summer. If you need some of these issuses resolved before then, we may need to add a 1.4.1 release with an earlier release date.

I think we really need this one to go in before JBossMessaging 1.0 is release (end of March) since performance is absolutely critical to us - it's one of the major points we'll be judged on.

For now, I have built my own copy of remoting with checking turned off.

Thx

[timfox]

JIRA task created:

http://jira.jboss.com/jira/browse/JBREM-310