none
How to check if a JMS queue is full from Biztalk using a JNBridge Adapter RRS feed

  • Question

  • Hi,

    We are posting messages to JMS queues to send it to a java application. We have a total of 4 queues each connected using an individual send port (JNBridge adapter). Is there a way to know if the target queue is full & if it is, then route the message to the next queue ?

    Can it be done in the orchestration/.net helper class? If yes, is there any tutorial/link that I can refer to ?


    Thursday, March 17, 2016 1:27 PM

Answers

  • Hi,

    The JNBridge BizTalk JMS adapter transport handler property, IgnoreServerExceptions, regardless if enabled or disabled, will not provide a mechanism for determining the state of a queue. This is because the server exception referred to uses the JMS Exception Listener specification. To wit (using quotes to indicate the copy/paste from the specification document):

    "If a JMS provider detects a problem with a connection, it will inform the
    connection’s ExceptionListener, if one has been registered."

    A full queue doesn't constitute a connection problem, so the approach won't work. The JMS specification, even the more recent 2.0 spec, does not provide any means to query queue state. A full queue is determined by server-side settings peculiar to the implementation. This is usually called "flow control". While the JMS specification doesn't address how a sender behaves if the queue is "full", the accepted behavior is for the thread to block until a consumer has removed enough messages in the queue to drop the count below the threshold. An exception will not be thrown by the JMS stack. A blocked thread isn't a good idea, but there is no timeout threshold in BizTalk. Rachit is correct, there's no good solution within BizTalk. Any solution will have to be server-side.

    The simplest solution is to increase the amount the queue can hold. A more complicated solution is to allow the JMS Server implementation--guessing WebSphere, here--to load balance each of the four queues. If the IBM implementation is clustered, then it would be possible to decrease the potential for a blocked thread in BizTalk. Another solution is to take a look at the consumer application/implementation. It may consume too slowly because it is resource bound or is bottle-necked in some way.

    William
    JNBridge, LLC


    William JNBridge, LLC

    • Marked as answer by S. Ak Monday, March 21, 2016 7:41 AM
    Friday, March 18, 2016 8:49 PM
  • Hi,

    IMO, there is no out-of-box solution to your requirement. 

    You have to make use of JMS Adapter send port property Ignore Server Exceptions.

    If a subscribed message is available for a send port, the adapter will first check to see if the JMS server has sent any asynchronous exceptions. If the property Ignore Server Exceptions is True, then any asynchronous exceptions sent by the JMS server will be ignored. If False, then the send port will disconnect if any asynchronous exception is sent by the JMS server. The send location will then post an error event and suspend the message. When the next subscribed message is available for the send port, the adapter will attempt to reconnect to the JMS server. If the server is still unavailable, the adapter will post an error event and suspend the message. The send port will not disable if the server is unavailable.

    You can setup an alert by using any of the monitoring tool like SCOM or BizTalk360. So, then your BizTalk administrator can act accordingly.

    If you have questions about the JNBridge JMS adapter, you contact with JNBridge support at support@jnbridge.com and info@jnbridge.com.



    Rachit Sikroria (Microsoft Azure MVP)

    • Proposed as answer by 440 Hertz Friday, March 18, 2016 6:48 PM
    • Unproposed as answer by 440 Hertz Friday, March 18, 2016 6:48 PM
    • Marked as answer by S. Ak Monday, March 21, 2016 7:41 AM
    Thursday, March 17, 2016 5:23 PM
    Moderator

All replies

  • Hi,

    IMO, there is no out-of-box solution to your requirement. 

    You have to make use of JMS Adapter send port property Ignore Server Exceptions.

    If a subscribed message is available for a send port, the adapter will first check to see if the JMS server has sent any asynchronous exceptions. If the property Ignore Server Exceptions is True, then any asynchronous exceptions sent by the JMS server will be ignored. If False, then the send port will disconnect if any asynchronous exception is sent by the JMS server. The send location will then post an error event and suspend the message. When the next subscribed message is available for the send port, the adapter will attempt to reconnect to the JMS server. If the server is still unavailable, the adapter will post an error event and suspend the message. The send port will not disable if the server is unavailable.

    You can setup an alert by using any of the monitoring tool like SCOM or BizTalk360. So, then your BizTalk administrator can act accordingly.

    If you have questions about the JNBridge JMS adapter, you contact with JNBridge support at support@jnbridge.com and info@jnbridge.com.



    Rachit Sikroria (Microsoft Azure MVP)

    • Proposed as answer by 440 Hertz Friday, March 18, 2016 6:48 PM
    • Unproposed as answer by 440 Hertz Friday, March 18, 2016 6:48 PM
    • Marked as answer by S. Ak Monday, March 21, 2016 7:41 AM
    Thursday, March 17, 2016 5:23 PM
    Moderator
  • Hi,

    The JNBridge BizTalk JMS adapter transport handler property, IgnoreServerExceptions, regardless if enabled or disabled, will not provide a mechanism for determining the state of a queue. This is because the server exception referred to uses the JMS Exception Listener specification. To wit (using quotes to indicate the copy/paste from the specification document):

    "If a JMS provider detects a problem with a connection, it will inform the
    connection’s ExceptionListener, if one has been registered."

    A full queue doesn't constitute a connection problem, so the approach won't work. The JMS specification, even the more recent 2.0 spec, does not provide any means to query queue state. A full queue is determined by server-side settings peculiar to the implementation. This is usually called "flow control". While the JMS specification doesn't address how a sender behaves if the queue is "full", the accepted behavior is for the thread to block until a consumer has removed enough messages in the queue to drop the count below the threshold. An exception will not be thrown by the JMS stack. A blocked thread isn't a good idea, but there is no timeout threshold in BizTalk. Rachit is correct, there's no good solution within BizTalk. Any solution will have to be server-side.

    The simplest solution is to increase the amount the queue can hold. A more complicated solution is to allow the JMS Server implementation--guessing WebSphere, here--to load balance each of the four queues. If the IBM implementation is clustered, then it would be possible to decrease the potential for a blocked thread in BizTalk. Another solution is to take a look at the consumer application/implementation. It may consume too slowly because it is resource bound or is bottle-necked in some way.

    William
    JNBridge, LLC


    William JNBridge, LLC

    • Marked as answer by S. Ak Monday, March 21, 2016 7:41 AM
    Friday, March 18, 2016 8:49 PM