MQSeries.net :: View topic - Flow subscribing to topic stops getting subscriptions

murdeep · Posted: Tue Jul 11, 2006 3:02 pm Post subject:

I have the following:

Environment: AIX 5.3 WMB V6.0.0.1

I have a simple flow that is comprised of:

JMSInput:Out-->Compute-->Trace
JMSInput:Catch-->Compute1-->Trace

The JMSInput is configured as a durable subscriber to a topic. The Transaction Mode is None.

The TCF is:

CCSID(819)
BROKERSUBQ(SYSTEM.JMS.ND.SUBSCRIBER.QUEUE)
PORT(1415)
SYNCPOINTALLGETS(NO)
PUBACKINT(25)
POLLINGINT(5000)
RECEIVEISOLATION(COMMITTED)
MSGSELECTION(CLIENT)
OUTCOMENOTIFICATION(YES)
CHANNEL(SYSTEM.DEF.SVRCONN)
OPTIMISTICPUBLICATION(NO)
BROKERCONQ(SYSTEM.BROKER.CONTROL.QUEUE)
USECONNPOOLING(YES)
HOSTNAME(127.0.0.1)
CLONESUPP(DISABLED)
LOCALADDRESS()
SPARSESUBS(NO)
VERSION(6)
BROKERCCSUBQ(SYSTEM.JMS.ND.CC.SUBSCRIBER.QUEUE)
PROCESSDURATION(UNKNOWN)
SSLRESETCOUNT(0)
CONNOPT(STANDARD)
BROKERQMGR(QMBKR01)
SSLFIPSREQUIRED(NO)
FAILIFQUIESCE(YES)
CLEANUP(SAFE)
RESCANINT(5000)
MSGBATCHSZ(10)
BROKERPUBQ(PUBLICATIONS.INPUT)
QMANAGER(QMBKR01)
BROKERVER(V2)
CLEANUPINT(3600000)
STATREFRESHINT(60000)
SUBSTORE(BROKER)
TRANSPORT(CLIENT)
TARGCLIENTMATCHING(YES)
CLIENTID(CLNT001)

The T is:

BROKERPUBQMGR()
FAILIFQUIESCE(YES)
BROKERDURSUBQ(SYSTEM.JMS.D.SUBSCRIBER.QUEUE)
TOPIC(Topics/Topic1)
BROKERPUBQ()
BROKERVER(V1)
PERSISTENCE(APP)
CCSID(1208)
TARGCLIENT(JMS)
ENCODING(NATIVE)
BROKERCCDURSUBQ(SYSTEM.JMS.D.CC.SUBSCRIBER.QUEUE)
MULTICAST(ASCF)
PRIORITY(APP)
EXPIRY(APP)

The Compute ESQL simply throws a user exception.

The Compute1 ESQL sets:

CopyEntireMessage();
Environment.Variables.Terminal = 'Catch';
Environment.Variables.ExceptionList = ExceptionList;

Trace traces ${Environment.Variables.ExceptionList} to a file.

Here are my observations:

When the publisher publishes a message the subscriber flow receives the publication as expected. When the flow throws the exception the flow traverses down the JMSInput:Catch terminal as expected. I know this because the compute1 sets the Environment.Variables.Terminal which is traced. Here's the problem, the message is saved on SYSTEM.JMS.D.SUBSCRIBER.QUEUE.

If I modify the Compute node esql to not throw the exception no message is saved on the durable subscriber queue.

Now the reason why I have put together this flow is because we saw messages building on the durable subscriber queue. Through trial and error I discovered that whenever an exception was encountered by the subscriber flow the message would be saved in the durable subscriber queue and it the flow no longer receives it's subscriptions. I have tried to find an option to prevent this from occurring with no luck. Once I modify my flow - commenting the throw exception - all the messages on the durable subscriber queue destined for my subscriber get processed.

Our plan is to have an exception processing subflow attached to the catch terminal to move the subscription message to a d/b for subsequent processing. This would imply that we don't want the copy on the durable subscriber queue when the exception is thrown.

I am thinking that this may have something to do with syncpoint control but have doubts since I would think wiring the catch terminal would cause a commit to be reached?

Any thoughts or ideas would be helpful.