I made two changes which I'll describe here. I haven't yet investigated the
mechanics of submitting patches.
The changes are both in the org.jboss.mq.il.oil package. Note there are analogous
places in the other il subpackages that may also need changing-- my current test
evidently doesn't exercise the other code paths.
In OILServerIL, add a line to the createConnection method:
private void createConnection()
throws Exception
{
socket = new Socket(addr, port);
// add the next line
socket.setTcpNoDelay(true);
in = new ObjectInputStream(new
BufferedInputStream(socket.getInputStream()));
out = new ObjectOutputStream(new
BufferedOutputStream(socket.getOutputStream()));
out.flush();
}
The same line gets added in OILServerILService
public void run()
{
try
{
while (running)
{
Socket socket = null;
try
{
socket = serverSocket.accept();
}
catch (java.io.InterruptedIOException e)
{
continue;
}
// it's possible that the service is no longer
// running but it got a connection, no point in
// starting up a thread!
//
if (!running)
{
if(socket != null)
{
try
{
socket.close();
}
catch(Exception e)
{
// do nothing
}
}
return;
}
try
{
socket.setSoTimeout(0);
// add next line
socket.setTcpNoDelay(true);
new Thread(new Client(socket), "OIL Worker").start();
}
catch(IOException ie)
{
if(log.isDebugEnabled())
{
log.debug("IOException processing client connection", ie);
log.debug("Dropping client connection, server will not
terminate");
}
}
}
}
catch (SocketException e)
{
// There is no easy way (other than string comparison) to
// determine if the socket exception is caused by connection
// reset by peer. In this case, it's okay to ignore both
// SocketException and IOException.
log.warn("SocketException occured (Connection reset by peer?). Cannot
initialize the OILServerILService.");
}
catch (IOException e)
{
log.warn("IOException occured. Cannot initialize the
OILServerILService.");
}
finally
{
try
{
serverSocket.close();
}
catch(Exception e)
{
log.debug("error closing server socket", e);
}
return;
}
}
Christian Riege wrote:
> hi,
>
> On Wed, 2002-01-16 at 10:58, Sacha Labourey wrote:
>
> > I guess that if you want to modify this, you need to make it optional.
> >
> > The TCPNODELAY flag is related to the Nagle's algorithm
>
> true.
>
> > This algorithm is made to avoid sending very small paquets each time you
> > send data through your socket [...]
>
> primarily useful for telnet/ssh style applications.
>
> > I am not familiar with JBossMQ code base but if you think that the
> > implementation could, at some time, send many small messages and would
>
> JBossMQ sends packets whenever a message needs to be delivered via the
> IL (except for the InVM layer but we can put that aside).
>
> > suffer from sending each time a paquet, then you should most probably make
> > this setting optional. But, on the opposite, if you think that your paquet
> > (*all* paquets, even ACK) always have a sufficient size and don't want Nagle
> > to take care of you, then it is up to you.
>
> ... don't forget the new pinger thread which tries to ping the server
> every once in a while to ensure its still up and running.
>
> bottom line: TCP_NODELAY should be set to *enabled* whenever you're in a
> low latency / high bandwidth situation, i.e. LAN or something similiar.
> I guess this applies to at the very least 80% of the JBossMQ
> installations out there.
>
> I would disable TCP_NODELAY only when being in a very low bandwidth /
> high latency situation.
>
> Loren, can you pls. submit a patch via SourceForge (or send it to this
> list) and we'll get this integrated into the codebase.
>
> Regarding Mac OS/X in this situation: it could very well be that their
> default mode of operation is to have TCP_NODELAY disabled by default,
> even when running on the loopback device -- you ARE using 127.0.0.1
> after all, right?. On my Linux box this is a switch when configuring the
> kernel (at least it has been when I was still building my own kernels
> ... which hasn't happened since 2.0.something).
>
> Regards,
> Christian
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development