|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Messages are not getting commiting |
« View previous topic :: View next topic » |
Author |
Message
|
dileep1985 |
Posted: Mon Oct 30, 2017 5:31 am Post subject: Messages are not getting commiting |
|
|
Novice
Joined: 15 Jul 2017 Posts: 15
|
Hi,
We have a batch flow where a batch will trigger the messages to get picked from a queue,and creates file. But we can see that messages are not getting commiting and files are not getting generating.
AMQ8450: Display queue status details.
QUEUE(EAI.ADWE.INB.IN) TYPE(QUEUE)
CURDEPTH(398192) IPPROCS(1)
LGETDATE(2017-10-30) LGETTIME(13.29.24)
LPUTDATE(2017-10-30) LPUTTIME(13.23.23)
MEDIALOG( ) MONQ(LOW)
MSGAGE(858203) OPPROCS(0)
QTIME(999999999, 999999999) UNCOM(99577)
We have increated the commit count to 100 and commit interval to 5 seconds.
No FDC generated.
Only error we are getting is MQGET call failed (2, 2024
Increased the MAXUNCOMMSGS but still no benefits
FLow is like below
Every 3 miniuite a batch flow will put a batch message to queue1 > Then MQ get node will retrieve the messages from IN queue --> and created the file |
|
Back to top |
|
 |
Vitor |
Posted: Mon Oct 30, 2017 5:45 am Post subject: Re: Messages are not getting commiting |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
dileep1985 wrote: |
AMQ8450: Display queue status details.
QUEUE(EAI.ADWE.INB.IN) TYPE(QUEUE)
CURDEPTH(398192) IPPROCS(1)
LGETDATE(2017-10-30) LGETTIME(13.29.24)
LPUTDATE(2017-10-30) LPUTTIME(13.23.23)
MEDIALOG( ) MONQ(LOW)
MSGAGE(858203) OPPROCS(0)
QTIME(999999999, 999999999) UNCOM(99577) |
So what's putting to this queue? If I understand your explanation correctly, it's not the flow.
dileep1985 wrote: |
We have increated the commit count to 100 and commit interval to 5 seconds. |
Where? In IIB? See my comment above?
dileep1985 wrote: |
No FDC generated. |
And no 2195 reason code indicating there should be one.
dileep1985 wrote: |
Only error we are getting is MQGET call failed (2, 2024 |
Unsurprising, though it does indicate your logs are sized a bit small for a Prod queue manager handling this volume.
dileep1985 wrote: |
Increased the MAXUNCOMMSGS but still no benefits |
Why did you think there would be.
dileep1985 wrote: |
FLow is like below
Every 3 miniuite a batch flow will put a batch message to queue1 > Then MQ get node will retrieve the messages from IN queue --> and created the file |
So nothing here is adding messages to the IN queue, which is the one with the 99,577 uncommitted messages. All this has is a trigger (batch) message, an IN queue with no messages it can read (because they're all uncommitted) and hence no file.
Tell whoever's writing to the IN queue that they might want to issue a commit every now and again. I suspect the problem is that, by design, they don't know when all the messages for a given file have been written so the keep adding more. And are doing it in a single unit of work. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
dileep1985 |
Posted: Mon Oct 30, 2017 5:54 am Post subject: |
|
|
Novice
Joined: 15 Jul 2017 Posts: 15
|
|
Back to top |
|
 |
Vitor |
Posted: Mon Oct 30, 2017 6:15 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
dileep1985 wrote: |
An order management system is putting the inventory details continously to the IN queue. In every 3 minuite an IIB flow will start another flow which will collect those records from the IN queue and will form a file . |
Vitor wrote: |
Tell whoever's writing to the IN queue that they might want to issue a commit every now and again |
Read that more carefully. Especially the part where it says:
Quote: |
To avoid this do an MQCMT on a more frequent basis. You should not normally exceed 100 MQPUTs within a unit of work |
Your flow isn't doing any puts, unless the functionality of an MQGet node is much different to what I think it is.
Show it to whoever owns your order management system, and ask how many MQPUTs they do between each MQCMIT. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Oct 30, 2017 6:17 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Also, to pre-empt your next problem, be aware that looping round with an MQGet node like this is the best & most reliable way yet discovered to run an execution group out of memory. Doing this with a queue of any significant depth will cause the flow to abend.
Seriously consider a redesign. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|