ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » execution group

Post new topic  Reply to topic Goto page Previous  1, 2, 3  Next
 execution group « View previous topic :: View next topic » 
Author Message
adubya
PostPosted: Wed Mar 16, 2016 2:03 am    Post subject: Reply with quote

Partisan

Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK

Gralgrathor wrote:
smdavies99 wrote:
cast some magic runes

As I recall, there was some naked dancing around a fire involved as well.


Don't get too close to the fire
Back to top
View user's profile Send private message Send e-mail
kirran
PostPosted: Wed Mar 16, 2016 8:25 am    Post subject: Reply with quote

Novice

Joined: 29 Feb 2016
Posts: 18

1)Flow(Mq input-----compute node-----mq output)----if message is transforming from this flow,if queue depth is full what will happen?
2)can we increase queue depth while application is running,then how can we increase?
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Mar 16, 2016 8:52 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

kirran wrote:
1)Flow(Mq input-----compute node-----mq output)----if message is transforming from this flow,if queue depth is full what will happen?


If the queue you're pointing the MQ Input node at is full, the put operation will fail and MQ will take the usual actions. If the queue you're pointing the MQ Output node at is full, your flow will receive a 2053 reason code in the usual way.

kirran wrote:
2)can we increase queue depth while application is running


Not while the queue has an active handle open.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
smdavies99
PostPosted: Wed Mar 16, 2016 11:47 am    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

Vitor wrote:


Not while the queue has an active handle open.


Are you sure about that? I just did a

Code:
alter ql(PLUGGH) maxdepth(10000)


when the IPPROCS were > 0 on both input and output.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Mar 16, 2016 11:51 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

smdavies99 wrote:
Vitor wrote:


Not while the queue has an active handle open.


Are you sure about that? I just did a

Code:
alter ql(PLUGGH) maxdepth(10000)


when the IPPROCS were > 0 on both input and output.


Never argue with a man who's just done what you said couldn't be done.

Maybe it's not true in newer (post 5.3) versions.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Gralgrathor
PostPosted: Wed Mar 16, 2016 12:43 pm    Post subject: Reply with quote

Master

Joined: 23 Jul 2009
Posts: 297

It's always a good idea to write a flow so that it can increase the maxdepth of its own output queue.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine.
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Wed Mar 16, 2016 3:01 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Gralgrathor wrote:
It's always a good idea to write a flow so that it can increase the maxdepth of its own output queue.

Ah, no.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
kirran
PostPosted: Wed Mar 16, 2016 8:51 pm    Post subject: Reply with quote

Novice

Joined: 29 Feb 2016
Posts: 18

if queue depth containing 50 messages,if i want to decrease to 20 messages,what will happen to 21-50 messages?where they will be lost?
plzz can u explain these......
Back to top
View user's profile Send private message
Gralgrathor
PostPosted: Wed Mar 16, 2016 10:06 pm    Post subject: Reply with quote

Master

Joined: 23 Jul 2009
Posts: 297

kirran wrote:
if queue depth containing 50 messages,if i want to decrease to 20 messages,what will happen to 21-50 messages?.

They'll stay on the queue until taken off. You just can't add any new messages until queue depth has dropped below maxdepth.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine.
Back to top
View user's profile Send private message Send e-mail
smdavies99
PostPosted: Wed Mar 16, 2016 10:47 pm    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

kirran wrote:
if queue depth containing 50 messages,if i want to decrease to 20 messages,what will happen to 21-50 messages?where they will be lost?
plzz can u explain these......


This is exactly why you need to do proper planning of your MQ Infrastructure.
You need to cover the what if scenarios such as

If the Consumer (i.e. reader) of messages on Queue PLUGGH.IN is down for a day and it is the end of the month how many messages are likely to build up on this queue?
Then you add a comfort factor to that value and there is your MAXDEPTH.

Many MQ systems have monitoring agents that check Queue Depths and raise alerts if the depth goes beyon a predicted limit. This gives the admis time to investigate the problem and if needed, increase the MAXDEPTH of the queue in order to allow the system to keep working.

You need to think beyond your limited scope and try to imagine a real world production environment where we try to mitigate against the law that says, it things can go wrong, they will.

My current project needs MAXDEPTH > 500,000 on a number of queues. This is because the consumer only comes on line twice a day. The End of year burst can easily top 350,000 messages in a day. Yes it is bad design (on the consumer system) but that is it. We can't change it so we work around the constraints.
Remember no storage is actually consumed on a queue when it has no messages on it.
So you need to plan your storage requirements as well. 500,000 messages needs more than 1GB of storage. Storage is cheap these days. I can buy close on 100Tb of disk storage for what it cost for a 2.4Mb (yes Megabytes) RK05 when I started out in this business.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
kirran
PostPosted: Thu Mar 17, 2016 3:50 am    Post subject: Reply with quote

Novice

Joined: 29 Feb 2016
Posts: 18

if mq input node properties has set to transactionMode = yes or no ,default.............plz explain it r give me link
Back to top
View user's profile Send private message
Gralgrathor
PostPosted: Thu Mar 17, 2016 4:10 am    Post subject: Reply with quote

Master

Joined: 23 Jul 2009
Posts: 297

kirran wrote:
plz explain it r give me link

Have you considered simply reading the documentation on the MQInput node?
https://www.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ac04560_.htm
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine.
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Thu Mar 17, 2016 4:29 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

PeterPotkay wrote:
Gralgrathor wrote:
It's always a good idea to write a flow so that it can increase the maxdepth of its own output queue.

Ah, no.




That's a horrible idea, for at least 2 reasons.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Gralgrathor
PostPosted: Thu Mar 17, 2016 4:46 am    Post subject: Reply with quote

Master

Joined: 23 Jul 2009
Posts: 297

Vitor wrote:
That's a horrible idea, for at least 2 reasons.

Planning is for wimps. Limits are for wimps. We should just give all queues an infinite maxdepth and simply hope for the best.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine.
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Thu Mar 17, 2016 5:17 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Gralgrathor wrote:
Vitor wrote:
That's a horrible idea, for at least 2 reasons.

Planning is for wimps. Limits are for wimps. We should just give all queues an infinite maxdepth and simply hope for the best.


As long as it's the programmers that get paged at 3 am on a Friday, after they've been out at the bar for 8 hours, sure.
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3  Next Page 2 of 3

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » execution group
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.