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

Reply via email to