Hi Shyamal, If connection is lost during or before punting the message into the wire in MessageProducer#send, 0-10 amqp client should throw the JMSException from send method, something like
javax.jms.JMSEception: Exception when sending message: Command was interrupted because of failover, before being sent. Also, JMSException indication that connection is closed is sent into ExceptionListener if such is set on Connection. If connection is lost after message is sent to the broker but broker has not confirmed message receiving, than JMSException should be sent into ExceptionListener indicating that connection has been closed. 0-8/0-9/0-9-1 ampq clients behaviour should be similar. This behaviour in AUTO_ACKNOWLEDGE conforms JMS spec According to chapter 4.4.14 of JMS specification When a client uses the AUTO_ACKNOWLEDGE mode it is not in direct control of message acknowledgment. Since such clients cannot know for certain if a particular message has been acknowledged, they must be prepared for re-delivery of the last consumed message. This can be caused by the client completing its work just prior to a failure that prevents the message acknowledgment from occurring. Only a session’s last consumed message is subject to this ambiguity. If you need more reliable delivery you should use transactions. Do you have ExceptionListener on your connection? Does any exception appear in that listener? Kind Regards, Alex On 17 May 2012 13:53, Shyamal Pandya1 <[email protected]> wrote: >> 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 > > Even if the connection is closed? Shouldn't there be an exception thrown in > such a case? > > -----Original Message----- > From: Rajith Attapattu [mailto:[email protected]] > Sent: Monday, May 14, 2012 10:23 PM > To: [email protected] > Subject: Re: qpid Java client keeps sending messages even if underlying > session/connection does not exist > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
