| Author |
Message
|
| Prasi |
 Posted: Wed Oct 23, 2013 9:10 am Post subject: Additional Instances |
 |
|
Apprentice
Joined: 03 Aug 2011
Posts: 42
|
Hi,
I have a requirement to get a different set of properties for a first instance of a message flow and when the second instance of the same message flow runs, the broker should take different set of properties. Is there anyway we can achieve that? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Oct 23, 2013 10:26 am Post subject: Re: Additional Instances |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Prasi wrote: |
| Is there anyway we can achieve that? |
No. It's an additional instance of the same flow with the same properties.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Wed Oct 23, 2013 11:43 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
I don't know. Don't underestimate the ability of some to wrangle code to do what they think they need it to do.
I wonder why it never occurs to some that maybe they need to rethink their design if the software makes it very hard to implement. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Oct 23, 2013 12:06 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Can you please explain WHY you want to do this?
What happens when the first thread finishes?
What happens when the second thread finishes?
How do you control who gets which set of variables?
Does the person who set this requirement really understand how threads and instances in broker works?
_________________
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 |
|
|
| Vitor |
| Posted: Wed Oct 23, 2013 12:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| joebuckeye wrote: |
| I don't know. Don't underestimate the ability of some to wrangle code to do what they think they need it to do. |
Like having different threads of the same process using different properties?
You can of course "wrangle" any number of solutions. None of them involve multiple instances of the same flow in the WMB sense.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Wed Oct 23, 2013 10:01 pm Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
Certainly NOT. You cannot get the SAME code to behave in two different ways.
You may decide that for the 1st MESSAGE the code does something, and from then for further messages it does something different.
What you are asking is that Instance one behave (ALWAYS) in a certain manner, and all other instances differently. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Oct 23, 2013 10:40 pm Post subject: Re: Additional Instances |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Prasi wrote: |
Hi,
I have a requirement to get a different set of properties for a first instance of a message flow and when the second instance of the same message flow runs, the broker should take different set of properties. |
The only reason I can imagine for that requirement (there may be others that even I cannot imagine, though)
is that you need to scale up the flow, because one single instance does not give enough throughput.
On the other hand two instances can sometimes give more throughput than the endpoint can handle.
So you think that making the second instance sleep a little you could achieve the optimal throughput.
If that is the case, the requirement is on too low level and already tied to somebody's idea on the possible implementation.
The correct requirement is that you need to implement message throttling.
Correct the requirement and you can forget about the hopeless task of trying to obtain thread numbers.
Google throttling algorithms. It is certainly possible to implement some of them even in ESQL.
Even if my guess was wrong, remember that the key of success is to get the requirements right. Rethink.
(Tell the architect to rethink) |
|
| Back to top |
|
|
| NealM |
| Posted: Thu Oct 24, 2013 10:52 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
I agree with other voices that the requirement seems wrong, but if I read the requirement to be that you need to identify that a 2nd instance of the flow has started before the current instance has completed, here is how to do it:
Have two embedded global cache setting/getting nodes in your flow, the first one at the beginning checks for and sets a value in embedded global cache (or use ia91 support pac if pre-MB8). The 2nd one at the flow end clears or changes that cache value. Optionally, you could just have the first node and rely on setting a value with a short shelf life. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Thu Oct 24, 2013 9:39 pm Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| NealM wrote: |
I agree with other voices that the requirement seems wrong, but if I read the requirement to be that you need to identify that a 2nd instance of the flow has started before the current instance has completed, here is how to do it:
Have two embedded global cache setting/getting nodes in your flow, the first one at the beginning checks for and sets a value in embedded global cache (or use ia91 support pac if pre-MB8). The 2nd one at the flow end clears or changes that cache value. Optionally, you could just have the first node and rely on setting a value with a short shelf life. |
I think you need to clarify your design. How do you distinguish between
1- 1st msg processed by instance 1, 2nd message processed by instance 2
2- both messages processed by instance 1 |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Oct 24, 2013 10:16 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| NealM wrote: |
I agree with other voices that the requirement seems wrong, but if I read the requirement to be that you need to identify that a 2nd instance of the flow has started before the current instance has completed, here is how to do it:
Have two embedded global cache setting/getting nodes in your flow, the first one at the beginning checks for and sets a value in embedded global cache (or use ia91 support pac if pre-MB8). The 2nd one at the flow end clears or changes that cache value. Optionally, you could just have the first node and rely on setting a value with a short shelf life. |
That's one way of figuring out if there is another flow instance running simultaneously.
But I got the impression that the OP has configured the flow to allow exactly one additional instance
and wants to know if the current instance is the default instance (probably not exactly the correct term for that)
that runs most of the messages or the additional instance.
Of course it's possible that the OP means message instances when he talks about flow instances...
I have never run thread level statistics, but because of the fact that you can run thread level statistics,
I have always assumed that there is a "default" thread that the listener calls most of the time
and the additional threads are instantiated when needed and kept running idle in a pool for a while.
Otherwise it would not make sense to run thread level statistics, would it?
Hopefully someone with better knowledge can correct me if I'm wrong.
I'm afraid we have already scared the OP off...
 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 25, 2013 6:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
I have always assumed that there is a "default" thread that the listener calls most of the time
and the additional threads are instantiated when needed and kept running idle in a pool for a while. |
I think it's slightly more complicated than that, but I could be wrong, too.
Easy enough to tell from a trace, though. |
|
| Back to top |
|
|
| NealM |
| Posted: Fri Oct 25, 2013 6:50 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Quote: |
I think you need to clarify your design. How do you distinguish between
1- 1st msg processed by instance 1, 2nd message processed by instance 2
2- both messages processed by instance 1 |
By using the cache value. Again, this is assuming I understand the OP's post correctly.
This of course could also be done a bit more slowly using a database table and an atomic section.
I was also originally going to suggest the flow be single instance and deployed to two EGs, but would still end up needing something like global cache to know whether the two instances were overlapping.
Regarding a "default" instance, I wonder if there is a difference if one specifies additional flow instances vs additional input node instances. But I really doubt if it is any more complicated than the EG keeping a couple counters. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Fri Oct 25, 2013 6:57 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| Quote: |
| By using the cache value.. |
you cannot distinguish between instances using a cache value, nor a database and atomic.
Deploying to two EGs would solve the problem as described. Have two different override parameter files, which means having two different message flows polling the same input queue (or whatever the input is ), and then there would be no control of what is processed where. |
|
| Back to top |
|
|
| NealM |
| Posted: Fri Oct 25, 2013 8:50 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Quote: |
| you cannot distinguish between instances using a cache value |
Using IA91:
In a Filter or Compute Node immediately after the input node (values are for a flow with two instances deployed in one EG):
| Code: |
DECLARE Status CHAR;
SET Environment.MyInstance.key = 'MyFlowInstance'
SET Status = createFromCache(Environment.MyInstance.key,
Environment.MyInstance, 'cacheValue', FALSE, FALSE);
IF Environment.MyInstance.cacheValue IS NULL THEN
-- guess what I'm the only instance!
SET Environment. MyInstance.myValue = '1';
SET Status = putIntoCache(Environment.MyInstance.key,
Environment.MyInstance.myValue, 60000, FALSE);
ELSE
-- guess I'm the second instance.
SET Environment. MyInstance.myValue = '2';
END IF; |
Then at the very end of the flow, in another Filter/Compute Node:
| Code: |
DECLARE Status CHAR;
IF Environment. MyInstance.myValue = '1' THEN
-- clear cache. The TRUE parm deletes key and value on retrieve
SET Status = createFromCache(Environment.MyInstance.key,
Environment.MyInstance, 'cacheValue', TRUE, FALSE);
END IF; |
So, exactly why is that not letting the flow know whether another instance is already running? |
|
| Back to top |
|
|
| dogorsy |
| Posted: Fri Oct 25, 2013 10:21 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| NealM wrote: |
| Quote: |
| you cannot distinguish between instances using a cache value |
Using IA91:
In a Filter or Compute Node immediately after the input node (values are for a flow with two instances deployed in one EG):
| Code: |
DECLARE Status CHAR;
SET Environment.MyInstance.key = 'MyFlowInstance'
SET Status = createFromCache(Environment.MyInstance.key,
Environment.MyInstance, 'cacheValue', FALSE, FALSE);
IF Environment.MyInstance.cacheValue IS NULL THEN
-- guess what I'm the only instance!
SET Environment. MyInstance.myValue = '1';
SET Status = putIntoCache(Environment.MyInstance.key,
Environment.MyInstance.myValue, 60000, FALSE);
ELSE
-- guess I'm the second instance.
SET Environment. MyInstance.myValue = '2';
END IF; |
Then at the very end of the flow, in another Filter/Compute Node:
| Code: |
DECLARE Status CHAR;
IF Environment. MyInstance.myValue = '1' THEN
-- clear cache. The TRUE parm deletes key and value on retrieve
SET Status = createFromCache(Environment.MyInstance.key,
Environment.MyInstance, 'cacheValue', TRUE, FALSE);
END IF; |
So, exactly why is that not letting the flow know whether another instance is already running? |
First: you are using IA91 which you don't need to. Have you not heard of ESQL shared variables ?
2nd: you are assuming there are only two instances deployed.
3rd and most important: you are assuming that once the 2nd instance is created, and when the two of them are idle, then the 1st incoming message will be processed by instance 1, can you guarantee that ? how do you know that it will not be picked up by instance 2 ? For example,
msg1 -> instance 1 set variable = 1
msg2 -> instance 2 set variable = 2
end msg2 ( instance 2 )
instance 1 set variable = null
msg3 -> instance 2 ( because instance 1 has not finished yet, but has reset the value to NULL ) set variable = 1
end msg1 ( instance 1 )
and that scenario is very likely, due to different paths and interruptions. |
|
| Back to top |
|
|
|
|
