And as a further aside, is there a particular reason you are accessing the underlying implementation classes (which are subject to change, and use of which obviously isnt portable to other providers) and using sync(), instead of using pure JMS code with a transacted session?
Also, your "msg.setJMSDeliveryMode(DeliveryMode.PERSISTENT);" call will not be achieving anything (as that method isnt for application use, as per the JMS spec), if you want to control message persistence you need to do so on the MessageProducer object or using its various send() methods. As it happens, PERSISTENT is the default delivery mod,e so unless you have changed it on the producer at some other point that is what you will be using...just not because of the quoted method call. Robbie On 14 May 2012 17:53, Rajith Attapattu <[email protected]> wrote: > Just to add to Alex's note, > On the flip side, If you select sync_publish it will affect performance > quite a bit. > > Rajith > > On Mon, May 14, 2012 at 10:28 AM, Oleksandr Rudyy <[email protected]> wrote: > >> Hi Shyamal, >> >> By default, MessageProducer#send operation is asynchronous, i.e. a >> message is put on a wire and producer does not wait for the broker >> confirmation. >> >> You can make this operation synchronous by setting JVM system property >> -Dsync_publish=all or -Dsync_publish=persistent or through connection >> URL option sync_publish. >> >> Setting sync_publish=persistent will make publisher to sync only >> persistent messages, whilst setting sync_publish=all will make >> publisher to sync both transient and persistent messages. >> >> This setting is only applicable for 0.10 amqp client (which is the >> default). >> >> Kind Regards, >> Alex >> >> On 12 May 2012 11:45, Shyamal Pandya1 <[email protected]> >> wrote: >> > Hi, >> > >> > I have a C++ QPID broker, to which a Java client sends messages >> (asynchronously). The broker and client versions are 0.14. I also have the >> qpid message store enabled. >> > >> > Whenever the queue reaches 80 % of its capacity, the broker closes the >> underlying session/connection. I verify this by running qpid-stat -c and >> see no connections from the client. >> > However, the client somehow keeps sending messages, there is no >> exception thrown. Only when a session.sync() is perform does it time out >> with a "Session DETACHED" error. >> > >> > Is this a bug, or am I doing something wrong? >> > >> > Code snippet: >> > >> > try >> > { >> > buffer.position(0); >> > >> > BytesMessage msg = qpidSession.createBytesMessage(); >> > >> > msg.setJMSDeliveryMode(DeliveryMode.PERSISTENT); >> > >> > msg.writeBytes(buffer.array()); >> > >> > publisher.publish(msg); // Shouldn't this throw an exception >> if the underlying connection is no longer there? >> > >> > // sync after every N messages >> > if(++msgCount >= MSG_SYNC_COUNT) >> > { >> > qpidSession.sync(); // This is where the error is thrown. >> > msgCount = 0; >> > } >> > >> > } >> > catch (JMSException e) >> > { >> > if (e.getErrorCode() != null) >> > { >> > log.error("JMSException error code: " + e.getErrorCode()); >> > } >> > >> > if (e.getLinkedException() != null) >> > { >> > log.error("JMSException linked exception: "+ e); >> > } >> > >> > connected.set(false); >> > throw e; >> > } >> > >> > >> > Thanks, >> > Shyamal >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
