Hi Di,
Other than your direct use of the destination implementation objects
as opposed to using JNDI or sesion.createQueue() calls I dont see
anything particularly wrong with your code below, but could you post
the complete reproducer code just in case? There has been some change
on trunk since
Hi Praveen,
I notice both your tests actually seem to enqueue and dequeue messages
at the same time (since you commit per publish and the message
listeners will already be recieving a message which then gets commited
by the next publish due to the single session in use, leaving a
message on the
Hi Fraser,
I must admit in retrospect I was probably overestimating the impact of
TCP_NODELAY. I had seen it make 30-40ms difference in performing
synchronous commands, of which there are actually probably only 3-4
during a connection creation which would explain your change in
results.
I expect
Hi Joe,
You can certainly bypass the ConnectionFactory and JNDI by using the
underlying implementation classes of the client, eg just using the
AMQConnection class directly. This wouldnt normally be advisable
though since it isnt intended as the supported API and can change
without notice, but
Hi Praveen,
Im not aware of tools which let you inspect .je files directly in a
nice way, only ones which dump the contents, although I have never
really looked for such tools so they may exist but again probably
wouldnt work while the broker was running.
The method of inspecting the broker
I believe Qpid 0.12 shipped with SLF4J 1.6 and so should default to
NO-OP logging (and a warning as such) out the box. If you havent done
any logging configuration yourself, that might suggest Log4J is
picking a log4j.properties or log4j.xml file up from the classpath
(assuming you are using
Those other classes/packages arent really what I'd call useful
examples and should really just be removed (we removed most of the
rest a while back for similar reasons, I'm not sure why those stayed).
Someone working close to me wrote a set of examples a while back, I'll
discuss contributing those
Robbie Gemmell wrote:
All that said, the worst I saw it perform is still twice as fast as
your best number below, which seems a little odd. Can I ask what you
were running your tests on? I dont imagine there is a JIRA for this,
no. I assume you are really interested in this due to running things
