MQSeries.net :: View topic

goffinf · Posted: Tue Feb 21, 2012 11:01 am Post subject:

Version: 6.1.0.9

OK, this is a bit of a punt, and I'm asking mainly because I'm struggling to replicate the reported behaviour and because Collector nodes are (a little) bit of an 'odd fish'. Its possible that someone here has seen this before and/or might be able to spot something that doesn't seem right. Its also possible that I'm misunderstanding something fundemental.

My Ops Support colleages have reported a problem with a flow which contains a Collector node. The flow is simple enough, its arrange like this :- (I'm just showing the Try part of the flow after the Collector) :-

MQInput -> Compute1 -> Collector -> Try/Catch -> Compute2 -> MQOutput

Compute1 provides a value for the Correlation Path configured in the Collector.

The Collector has only ONE dynamic input terminal (and the Control is not wired).

The properties set are :-

Quantity: 500
Timeout: 60
Expiry: 300

Persistence Mode: Non persistent
Event Coordination: Disabled

So here, collections should be propagated when either 500 messages for a correlation path have arrived or 60 seconds elapsed after the first message is received for any collection that has at least one message. Thats right isn't it ?

So to the *odd* behaviour.

Apparently when a collection is complete (either by quantity or timeout), the flow stops processing any further messages from the MQInput and they just build up. Eventually that queue hits its max depth !

I haven't witnessed that yet but certainly others have. I'm currently at a loss here to understand why. No error or abends happen ?

The other unfortunate part is that this happens in our PROD environment and that means its difficult to set up tracing and the like, and I haven't yet been able to replicate this problem elsewhere (I know that points to an environment thing, but as you might expect, I am being assured by the guys that look after these things that everything is the same - hummph).

AFAIK the SYSTEM.BROKER.EDA.EVENT/COLLECTOR queues aren't maxed out. They have some messages on them but only what you would expect from as yet incomplete collections.

I'm not 100% certain about the accuracy of the statement, '.. no further messages are read from the MQInput queue'. However one thing of note is that the MQInput node is NOT transactional so messages should not be getting blown back onto that queue I suppose (I guess its possible that the arrival rate of the messages outstrips the retrieval rate from the queue, but I doubt it (they are monitoring event message though so theres a good deal of them coming through).

One other thing that might be worth a mention ..

In searching this forum I noted a comment from mqjeff about whether configuring additional instances has any effect on the output side of a Collector (the suggestion was it doesn't). Well this flow *is* configured for additional instances (4 I think), but I don't know if that has any impact on the behaviour as reported.

Grateful for any insights or even 'might be' type comments. I'm in investigate mode so don't mind at all following a hint however tenuous and I'll be happy to feed back anything of note.

Regards

Fraser.