Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 jwjjj1983@gmail.com does not designate 216.139.236.26 as permitted sender)
Date: Fri, 20 Jun 2014 16:09:21 -0700 (PDT)
From: smartdog <jwjjj1983@gmail.com>
To: users@qpid.apache.org
Message-ID: <1403305761093-7609542.post@n2.nabble.com>
In-Reply-To: <53A41DBE.90408@redhat.com>
References: <1403028652612-7609368.post@n2.nabble.com>
 <53A0B08D.3040706@redhat.com> <1403040922603-7609374.post@n2.nabble.com>
 <53A14A0D.8030301@redhat.com> <53A1CEC3.30300@blueyonder.co.uk>
 <53A1F5AF.6030208@redhat.com> <1403211834445-7609503.post@n2.nabble.com>
 <53A41DBE.90408@redhat.com>
Subject: Re: Why performance of sending durable messages to qpid queue is
 really bad?
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for that. After changing it from 500 to 10, I am able to get 20ms
latency for a send. Pretty cool.

But I cannot reproduce it on another machine, i.e. after I copied the
rebuilt qpidd executable with reduced timeout to another machine, the
latency is still 1000ms on that machine, unless I rebuild qpidd on that
machine, then all qpidd executables have 20ms latency.

So I guess the build process changed something only on the machine, not the
qpidd executable, legacystore.so, etc. How to work around this because we
don't want to build qpidd from src on every machine.


--
View this message in context: http://qpid.2158936.n2.nabble.com/Why-performance-of-sending-durable-messages-to-qpid-queue-is-really-bad-tp7609368p7609542.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org