You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by ffrenchm <ff...@gmail.com> on 2009/02/25 14:43:02 UTC
QPid JMS client configuration
Hello,
some new questions for you guys :) For my bench I want to send message with
different size. I'm currently testing the send of 262144 bytes messages.
Unfortunately I get this error :
org.apache.qpid.transport.SessionException: timed out waiting for completion
at org.apache.qpid.transport.Session.invoke(Session.java:543)
at
org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
at
org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
at
org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
at
org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
at
org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:258)
at Bench.JMSBench.jms_publisher(JMSBench.java:79)
at Bench.runBench$2.run(runBench.java:87)
at java.lang.Thread.run(Thread.java:619)
I saw there are some configuration to tune my JMS client
(org.apache.qpid.client.configuration.ClientProperties.java) and
particularly this one : IDLE_TIMEOUT_PROP_NAME. I think I can tune this
through the JVM parameters (-Didle_timeout= ... ) but I would like to be
sure it's the good one to tune and what could be the good value to avoid
this error (I do not know the default).
Another parameter I saw is the READ_BUFFER_LIMIT_DEFAULT &
WRITE_BUFFER_LIMIT_DEFAULT hardly defined to 262144 and which could be
change (I guess) thanks JVM option qpid.read.buffer.limit. In my bench I
want to send messages of 4194304 bytes do you think I should change this
parameter to 4194304 to get best performances ?
Thanks for all...
--
View this message in context: http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2383781.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QPid JMS client configuration
Posted by ffrenchm <ff...@gmail.com>.
Another question about the JMS configuration and the message flow control. I
saw that this parameter is set to false by default
org.apache.qpid.transport.Session.java and I guess consequently there is no
flow control in the JMS api because I do not see any call of the
messageSetFlowMode method... Did I miss something? Is there a way to tune my
JMS client to enable the flow control ?
Thanks ! :)
ffrenchm wrote:
>
> Hello,
>
> some new questions for you guys :) For my bench I want to send message
> with different size. I'm currently testing the send of 262144 bytes
> messages. Unfortunately I get this error :
>
> org.apache.qpid.transport.SessionException: timed out waiting for
> completion
> at org.apache.qpid.transport.Session.invoke(Session.java:543)
> at
> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
> at
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
> at
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
> at
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
> at
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:258)
> at Bench.JMSBench.jms_publisher(JMSBench.java:79)
> at Bench.runBench$2.run(runBench.java:87)
> at java.lang.Thread.run(Thread.java:619)
>
> I saw there are some configuration to tune my JMS client
> (org.apache.qpid.client.configuration.ClientProperties.java) and
> particularly this one : IDLE_TIMEOUT_PROP_NAME. I think I can tune this
> through the JVM parameters (-Didle_timeout= ... ) but I would like to be
> sure it's the good one to tune and what could be the good value to avoid
> this error (I do not know the default).
>
> Another parameter I saw is the READ_BUFFER_LIMIT_DEFAULT &
> WRITE_BUFFER_LIMIT_DEFAULT hardly defined to 262144 and which could be
> change (I guess) thanks JVM option qpid.read.buffer.limit. In my bench I
> want to send messages of 4194304 bytes do you think I should change this
> parameter to 4194304 to get best performances ?
>
> Thanks for all...
>
>
>
--
View this message in context: http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2383853.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QPid JMS client configuration
Posted by ffrenchm <ff...@gmail.com>.
Hello,
thanks for your answers. I'm using the broker built from the trunk.
I'll test the M4 release now.
++
Rajith Attapattu wrote:
>
> ffrench,
>
> Could you please let us know if you using the client and broker built
> from trunk or whether it's from a release.
>
> Regards,
>
> Rajith
>
> On Wed, Feb 25, 2009 at 4:47 PM, Rajith Attapattu <ra...@gmail.com>
> wrote:
>> Hello ffrench,
>>
>> The -Didle_timeout is used to configure the socket timeout to figure
>> out a connection a connection failure before the tcp stack notifies
>> us.
>> Basically the idle timeout is twice the heartbeat interval set in the
>> broker. This has no connection with performance and also not with the
>> problem you are seeing above.
>>
>> It looks like the client is waiting for the broker to send a response
>> to it's flush request and it is timing out.
>> Since you are sending messages with a large size you are trigging this
>> logic.
>>
>> Experiment with setting -Dqpid.session.byte_limit to a larger size and
>> see what happens.
>> By default the value for "qpid.session.byte_limit" is 1024*1024.
>> If the broker does not respond to the flush request then setting the
>> above to a higher value will only prolong the problem.
>>
>> So please post the broker log as we could figure out whats happening
>> on the other end. It maybe that the broker does not respond to the
>> flush request in reasonable time frame or at all (and it is not bound
>> to do so either).
>> If thats the case we could experiment with setting the sync bit.
>>
>>
>> Regards,
>>
>> Rajith
>>
>>
>> On Wed, Feb 25, 2009 at 8:43 AM, ffrenchm <ff...@gmail.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> some new questions for you guys :) For my bench I want to send message
>>> with
>>> different size. I'm currently testing the send of 262144 bytes messages.
>>> Unfortunately I get this error :
>>>
>>> org.apache.qpid.transport.SessionException: timed out waiting for
>>> completion
>>> at org.apache.qpid.transport.Session.invoke(Session.java:543)
>>> at
>>> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
>>> at
>>> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
>>> at
>>> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>>> at
>>> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>>> at
>>> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:258)
>>> at Bench.JMSBench.jms_publisher(JMSBench.java:79)
>>> at Bench.runBench$2.run(runBench.java:87)
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> I saw there are some configuration to tune my JMS client
>>> (org.apache.qpid.client.configuration.ClientProperties.java) and
>>> particularly this one : IDLE_TIMEOUT_PROP_NAME. I think I can tune this
>>> through the JVM parameters (-Didle_timeout= ... ) but I would like to be
>>> sure it's the good one to tune and what could be the good value to avoid
>>> this error (I do not know the default).
>>>
>>> Another parameter I saw is the READ_BUFFER_LIMIT_DEFAULT &
>>> WRITE_BUFFER_LIMIT_DEFAULT hardly defined to 262144 and which could be
>>> change (I guess) thanks JVM option qpid.read.buffer.limit. In my bench I
>>> want to send messages of 4194304 bytes do you think I should change this
>>> parameter to 4194304 to get best performances ?
>>>
>>> Thanks for all...
>>>
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2383781.html
>>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
>
--
View this message in context: http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2388636.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QPid JMS client configuration
Posted by Rajith Attapattu <ra...@gmail.com>.
ffrench,
Could you please let us know if you using the client and broker built
from trunk or whether it's from a release.
Regards,
Rajith
On Wed, Feb 25, 2009 at 4:47 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> Hello ffrench,
>
> The -Didle_timeout is used to configure the socket timeout to figure
> out a connection a connection failure before the tcp stack notifies
> us.
> Basically the idle timeout is twice the heartbeat interval set in the
> broker. This has no connection with performance and also not with the
> problem you are seeing above.
>
> It looks like the client is waiting for the broker to send a response
> to it's flush request and it is timing out.
> Since you are sending messages with a large size you are trigging this logic.
>
> Experiment with setting -Dqpid.session.byte_limit to a larger size and
> see what happens.
> By default the value for "qpid.session.byte_limit" is 1024*1024.
> If the broker does not respond to the flush request then setting the
> above to a higher value will only prolong the problem.
>
> So please post the broker log as we could figure out whats happening
> on the other end. It maybe that the broker does not respond to the
> flush request in reasonable time frame or at all (and it is not bound
> to do so either).
> If thats the case we could experiment with setting the sync bit.
>
>
> Regards,
>
> Rajith
>
>
> On Wed, Feb 25, 2009 at 8:43 AM, ffrenchm <ff...@gmail.com> wrote:
>>
>> Hello,
>>
>> some new questions for you guys :) For my bench I want to send message with
>> different size. I'm currently testing the send of 262144 bytes messages.
>> Unfortunately I get this error :
>>
>> org.apache.qpid.transport.SessionException: timed out waiting for completion
>> at org.apache.qpid.transport.Session.invoke(Session.java:543)
>> at
>> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
>> at
>> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
>> at
>> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>> at
>> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>> at
>> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:258)
>> at Bench.JMSBench.jms_publisher(JMSBench.java:79)
>> at Bench.runBench$2.run(runBench.java:87)
>> at java.lang.Thread.run(Thread.java:619)
>>
>> I saw there are some configuration to tune my JMS client
>> (org.apache.qpid.client.configuration.ClientProperties.java) and
>> particularly this one : IDLE_TIMEOUT_PROP_NAME. I think I can tune this
>> through the JVM parameters (-Didle_timeout= ... ) but I would like to be
>> sure it's the good one to tune and what could be the good value to avoid
>> this error (I do not know the default).
>>
>> Another parameter I saw is the READ_BUFFER_LIMIT_DEFAULT &
>> WRITE_BUFFER_LIMIT_DEFAULT hardly defined to 262144 and which could be
>> change (I guess) thanks JVM option qpid.read.buffer.limit. In my bench I
>> want to send messages of 4194304 bytes do you think I should change this
>> parameter to 4194304 to get best performances ?
>>
>> Thanks for all...
>>
>>
>> --
>> View this message in context: http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2383781.html
>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QPid JMS client configuration
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi ffrench,
Glad to know. Please let us know if u have nay further queries.
Regards,
Rajith
On Thu, Feb 26, 2009 at 7:24 AM, ffrenchm <ff...@gmail.com> wrote:
>
> Hello,
>
> When setting the trace on the QPID C++ broker I do not reproduce the
> problem.
>
> Then I did some modifications on my JMS client by setting my jms consumer
> and publisher methods to final static. Since this I can't reproduce the pb
> anymore with the trunk qpid release without the trace.
>
> I'll keep you in touch when I'll get more informations...
>
> Thanks for all.
>
>
> Rajith Attapattu wrote:
>>
>> Hello ffrench,
>>
>> The -Didle_timeout is used to configure the socket timeout to figure
>> out a connection a connection failure before the tcp stack notifies
>> us.
>> Basically the idle timeout is twice the heartbeat interval set in the
>> broker. This has no connection with performance and also not with the
>> problem you are seeing above.
>>
>> It looks like the client is waiting for the broker to send a response
>> to it's flush request and it is timing out.
>> Since you are sending messages with a large size you are trigging this
>> logic.
>>
>> Experiment with setting -Dqpid.session.byte_limit to a larger size and
>> see what happens.
>> By default the value for "qpid.session.byte_limit" is 1024*1024.
>> If the broker does not respond to the flush request then setting the
>> above to a higher value will only prolong the problem.
>>
>> So please post the broker log as we could figure out whats happening
>> on the other end. It maybe that the broker does not respond to the
>> flush request in reasonable time frame or at all (and it is not bound
>> to do so either).
>> If thats the case we could experiment with setting the sync bit.
>>
>>
>> Regards,
>>
>> Rajith
>>
>>
>> On Wed, Feb 25, 2009 at 8:43 AM, ffrenchm <ff...@gmail.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> some new questions for you guys :) For my bench I want to send message
>>> with
>>> different size. I'm currently testing the send of 262144 bytes messages.
>>> Unfortunately I get this error :
>>>
>>> org.apache.qpid.transport.SessionException: timed out waiting for
>>> completion
>>> at org.apache.qpid.transport.Session.invoke(Session.java:543)
>>> at
>>> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
>>> at
>>> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
>>> at
>>> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>>> at
>>> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>>> at
>>> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:258)
>>> at Bench.JMSBench.jms_publisher(JMSBench.java:79)
>>> at Bench.runBench$2.run(runBench.java:87)
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> I saw there are some configuration to tune my JMS client
>>> (org.apache.qpid.client.configuration.ClientProperties.java) and
>>> particularly this one : IDLE_TIMEOUT_PROP_NAME. I think I can tune this
>>> through the JVM parameters (-Didle_timeout= ... ) but I would like to be
>>> sure it's the good one to tune and what could be the good value to avoid
>>> this error (I do not know the default).
>>>
>>> Another parameter I saw is the READ_BUFFER_LIMIT_DEFAULT &
>>> WRITE_BUFFER_LIMIT_DEFAULT hardly defined to 262144 and which could be
>>> change (I guess) thanks JVM option qpid.read.buffer.limit. In my bench I
>>> want to send messages of 4194304 bytes do you think I should change this
>>> parameter to 4194304 to get best performances ?
>>>
>>> Thanks for all...
>>>
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2383781.html
>>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2389301.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QPid JMS client configuration
Posted by ffrenchm <ff...@gmail.com>.
Hello,
When setting the trace on the QPID C++ broker I do not reproduce the
problem.
Then I did some modifications on my JMS client by setting my jms consumer
and publisher methods to final static. Since this I can't reproduce the pb
anymore with the trunk qpid release without the trace.
I'll keep you in touch when I'll get more informations...
Thanks for all.
Rajith Attapattu wrote:
>
> Hello ffrench,
>
> The -Didle_timeout is used to configure the socket timeout to figure
> out a connection a connection failure before the tcp stack notifies
> us.
> Basically the idle timeout is twice the heartbeat interval set in the
> broker. This has no connection with performance and also not with the
> problem you are seeing above.
>
> It looks like the client is waiting for the broker to send a response
> to it's flush request and it is timing out.
> Since you are sending messages with a large size you are trigging this
> logic.
>
> Experiment with setting -Dqpid.session.byte_limit to a larger size and
> see what happens.
> By default the value for "qpid.session.byte_limit" is 1024*1024.
> If the broker does not respond to the flush request then setting the
> above to a higher value will only prolong the problem.
>
> So please post the broker log as we could figure out whats happening
> on the other end. It maybe that the broker does not respond to the
> flush request in reasonable time frame or at all (and it is not bound
> to do so either).
> If thats the case we could experiment with setting the sync bit.
>
>
> Regards,
>
> Rajith
>
>
> On Wed, Feb 25, 2009 at 8:43 AM, ffrenchm <ff...@gmail.com>
> wrote:
>>
>> Hello,
>>
>> some new questions for you guys :) For my bench I want to send message
>> with
>> different size. I'm currently testing the send of 262144 bytes messages.
>> Unfortunately I get this error :
>>
>> org.apache.qpid.transport.SessionException: timed out waiting for
>> completion
>> at org.apache.qpid.transport.Session.invoke(Session.java:543)
>> at
>> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
>> at
>> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
>> at
>> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>> at
>> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>> at
>> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:258)
>> at Bench.JMSBench.jms_publisher(JMSBench.java:79)
>> at Bench.runBench$2.run(runBench.java:87)
>> at java.lang.Thread.run(Thread.java:619)
>>
>> I saw there are some configuration to tune my JMS client
>> (org.apache.qpid.client.configuration.ClientProperties.java) and
>> particularly this one : IDLE_TIMEOUT_PROP_NAME. I think I can tune this
>> through the JVM parameters (-Didle_timeout= ... ) but I would like to be
>> sure it's the good one to tune and what could be the good value to avoid
>> this error (I do not know the default).
>>
>> Another parameter I saw is the READ_BUFFER_LIMIT_DEFAULT &
>> WRITE_BUFFER_LIMIT_DEFAULT hardly defined to 262144 and which could be
>> change (I guess) thanks JVM option qpid.read.buffer.limit. In my bench I
>> want to send messages of 4194304 bytes do you think I should change this
>> parameter to 4194304 to get best performances ?
>>
>> Thanks for all...
>>
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2383781.html
>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
>
--
View this message in context: http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2389301.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QPid JMS client configuration
Posted by Rajith Attapattu <ra...@gmail.com>.
Hello ffrench,
The -Didle_timeout is used to configure the socket timeout to figure
out a connection a connection failure before the tcp stack notifies
us.
Basically the idle timeout is twice the heartbeat interval set in the
broker. This has no connection with performance and also not with the
problem you are seeing above.
It looks like the client is waiting for the broker to send a response
to it's flush request and it is timing out.
Since you are sending messages with a large size you are trigging this logic.
Experiment with setting -Dqpid.session.byte_limit to a larger size and
see what happens.
By default the value for "qpid.session.byte_limit" is 1024*1024.
If the broker does not respond to the flush request then setting the
above to a higher value will only prolong the problem.
So please post the broker log as we could figure out whats happening
on the other end. It maybe that the broker does not respond to the
flush request in reasonable time frame or at all (and it is not bound
to do so either).
If thats the case we could experiment with setting the sync bit.
Regards,
Rajith
On Wed, Feb 25, 2009 at 8:43 AM, ffrenchm <ff...@gmail.com> wrote:
>
> Hello,
>
> some new questions for you guys :) For my bench I want to send message with
> different size. I'm currently testing the send of 262144 bytes messages.
> Unfortunately I get this error :
>
> org.apache.qpid.transport.SessionException: timed out waiting for completion
> at org.apache.qpid.transport.Session.invoke(Session.java:543)
> at
> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
> at
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
> at
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
> at
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
> at
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:258)
> at Bench.JMSBench.jms_publisher(JMSBench.java:79)
> at Bench.runBench$2.run(runBench.java:87)
> at java.lang.Thread.run(Thread.java:619)
>
> I saw there are some configuration to tune my JMS client
> (org.apache.qpid.client.configuration.ClientProperties.java) and
> particularly this one : IDLE_TIMEOUT_PROP_NAME. I think I can tune this
> through the JVM parameters (-Didle_timeout= ... ) but I would like to be
> sure it's the good one to tune and what could be the good value to avoid
> this error (I do not know the default).
>
> Another parameter I saw is the READ_BUFFER_LIMIT_DEFAULT &
> WRITE_BUFFER_LIMIT_DEFAULT hardly defined to 262144 and which could be
> change (I guess) thanks JVM option qpid.read.buffer.limit. In my bench I
> want to send messages of 4194304 bytes do you think I should change this
> parameter to 4194304 to get best performances ?
>
> Thanks for all...
>
>
> --
> View this message in context: http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2383781.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QPid JMS client configuration
Posted by ffrenchm <ff...@gmail.com>.
Is there anybody who can explains me from where comes this exception
(org.apache.qpid.transport.SessionException: timed out waiting for
completion) and how to avoid it ? I'm currently blocked on my bench and my
study is coming now to its dead line.
Thanks ...
ffrenchm wrote:
>
> Hello,
>
> some new questions for you guys :) For my bench I want to send message
> with different size. I'm currently testing the send of 262144 bytes
> messages. Unfortunately I get this error :
>
> org.apache.qpid.transport.SessionException: timed out waiting for
> completion
> at org.apache.qpid.transport.Session.invoke(Session.java:543)
> at
> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
> at
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
> at
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
> at
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
> at
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:258)
> at Bench.JMSBench.jms_publisher(JMSBench.java:79)
> at Bench.runBench$2.run(runBench.java:87)
> at java.lang.Thread.run(Thread.java:619)
>
> I saw there are some configuration to tune my JMS client
> (org.apache.qpid.client.configuration.ClientProperties.java) and
> particularly this one : IDLE_TIMEOUT_PROP_NAME. I think I can tune this
> through the JVM parameters (-Didle_timeout= ... ) but I would like to be
> sure it's the good one to tune and what could be the good value to avoid
> this error (I do not know the default).
>
> Another parameter I saw is the READ_BUFFER_LIMIT_DEFAULT &
> WRITE_BUFFER_LIMIT_DEFAULT hardly defined to 262144 and which could be
> change (I guess) thanks JVM option qpid.read.buffer.limit. In my bench I
> want to send messages of 4194304 bytes do you think I should change this
> parameter to 4194304 to get best performances ?
>
> Thanks for all...
>
>
>
--
View this message in context: http://n2.nabble.com/QPid-JMS-client-configuration-tp2383781p2385118.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org