Hi again,

my experiments have also showed that having Session with
CLIENT_ACKNOWLEDGE mode instead of transacted session and issuing
message.acknowledge() after each consumed persistent message also
gives huge performance grow comparing to Session.commit(). Now I can
consume more than 3000 msg / sec.

I thought that SESSION_TRANSACTED should be similar to
CLIENT_ACKNOWLEDGE from the perspective of broker actions it has to
perform after each commit or acknowledge. It should be also similar
from logical perspective, especially if I issue Session.recover() to
make redelivery policy work when the consumer cannot acknowledge
message. I found one explanation at sun.com:

"Using CLIENT_ACKNOWLEDGE mode is similar to using transactions,
except there is no guarantee that all acknowledgments will be
processed together if a provider fails during processing."

So I have two questions:

1. Why performance difference is so huge between SESSION_TRANSACTED
and CLIENT_ACKNOWLEDGE modes?
2. What I'm i loosing (gaining) using CLIENT_ACKNOWLEDGE instead of
SESSION_TRANSACTED?

Regards,
Dziugas Baltrunas

On 9/5/07, Dziugas Baltrunas <dziugas@baltrunas.lt> wrote:
> Hi,
>
> resolving TCP_NODELAY issue made Session.commit() fast after each
> non-persistent message consumption when broker is running Linux.
>
> However, commit is no longer fast when consuming persistent messages.
> Performance running broker both on Windows and Linux is no more than
> 10 msg / sec.
>
> I suppose this is already disk bound, but strange is that performance
> degrades about 100 times comparing to transactional non-persistent
> messaging.
>
> Regards,
> Dziugas Baltrunas
>
> On 9/5/07, James Strachan <james.strachan@gmail.com> wrote:
> > Ah my mistake - that only works on the client side - not on the broker side.
> >
> > On 9/5/07, James Strachan <james.strachan@gmail.com> wrote:
> > > As described on AMQ_1156, why not use
> > >
> > > ?socket.tcpNoDelay=true
> > >
> > >
> > > On 9/5/07, Dziugas Baltrunas <dziugas@baltrunas.lt> wrote:
> > > > Hi,
> > > >
> > > > I hope tcpNoDelay flag will be updated in next release of ActiveMQ.
> > > > For those using 4.1.1 version there are two workarounds:
> > > >
> > > > 1. Modify the source code as described in AMQ-1156.
> > > > 2. In lib/activemq-core-4.1.1.jar edit
> > > > META-INF/services/org/apache/activemq/transport/tcp and change
> > > >
> > > > class=org.apache.activemq.transport.tcp.TcpTransportFactory
> > > >
> > > > to
> > > >
> > > > class=your.package.YourTcpTransportFactory
> > > >
> > > > Then create your.package.YourTcpTransportFactory class witch extends
> > > > org.apache.activemq.transport.tcp.TcpTransportFactory and overrides
> > > > single method as follows:
> > > >
> > > > public class YourTcpTransportFactory extends TcpTransportFactory {
> > > >
> > > >   public Transport compositeConfigure(Transport transport, WireFormat
> > > > format, Map options) {
> > > >     TcpTransport tcpTransport = (TcpTransport)
> > > > transport.narrow(TcpTransport.class);
> > > >     tcpTransport.setTcpNoDelay(new Boolean(true));
> > > >     return super.compositeConfigure(transport, format, options);
> > > >   }
> > > > }
> > > >
> > > > Don't forget to put your class in ActiveMQ classpath. One way is to
> > > > pack YourTcpTransportFactory into jar and put in ActiveMQ lib/ folder.
> > > >
> > > > Regards,
> > > > Dziugas Baltrunas
> > > >
> > > > On 9/4/07, Dziugas Baltrunas <dziugas@baltrunas.lt> wrote:
> > > > > Hi,
> > > > >
> > > > > what is the right way to turn off TCP_NODELAY on Apache ActiveMQ 4.1.1
> > > > > (server side)? Looks like none of the options (socket.tcpNoDelay,
> > > > > wireFormat.tcpNoDelayEnabled, tcpNoDelay) work as described in
> > > > > AMQ-1156.
> > > > >
> > > > > Regards,
> > > > > Dziugas Baltrunas
> > > > >
> > > > > On 9/4/07, James Strachan <james.strachan@gmail.com> wrote:
> > > > > > On 9/4/07, Dziugas Baltrunas <dziugas@baltrunas.lt> wrote:
> > > > > > > Hi again,
> > > > > > >
> > > > > > > looks like I was wrong - running daemon on Windows increases the
> > > > > > > performance dramatically and I can now consume 1000 messages with
> > > > > > > commit after each message in less then 500 ms. And this is client
> > > > > > > independent, i.e. both consumer from Linux and Windows can consume
> > > > > > > fast from ActiveMQ running on Windows but slow if ActiveMQ runs on
> > > > > > > Linux.
> > > > > > >
> > > > > > > So it appears that my problem is the same as described AMQ-1137.
> > > > > > >
> > > > > > > Any hints how to "tune" ActiveMQ running on Linux to speed up commit operations?
> > > > > >
> > > > > > Usually thats the nagler / tcp-nodelay issue
> > > > > >
> > > > > > --
> > > > > > James
> > > > > > -------
> > > > > > http://macstrac.blogspot.com/
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > James
> > > -------
> > > http://macstrac.blogspot.com/
> > >
> >
> >
> > --
> > James
> > -------
> > http://macstrac.blogspot.com/
> >
>