| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Need an advice on this topology |
« View previous topic :: View next topic » |
| Author |
Message
|
| yalmasri |
 Posted: Wed Nov 20, 2013 11:52 pm Post subject: Re: Need an advice on this topology |
 |
|
Centurion
Joined: 18 Jun 2008
Posts: 110
|
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Thu Nov 21, 2013 1:27 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
It is also unlimited on Solaris however.....
The combined experiences of the people have commented on this thread are very much in accordance with what I consider to be best practice. By this I mean that having 700 flows in one EG is not really a good idea at all.
_________________
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 |
|
|
| yalmasri |
| Posted: Thu Nov 21, 2013 2:11 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008
Posts: 110
|
| Vitor wrote: |
| yalmasri wrote: |
| No, I'm going to use mqsichangeproperties the same way you'll be using it when you want to change the memory settings for your 100-EGs Broker, and in all cases the broker all together need to be restarted, not just your EGs. So this is irrelevant to how many EGs you have in your Broker. |
No, you restart the EG not the broker.
| yalmasri wrote: |
| Now you tell me what would you do if your WAS started to throw OoM exceptions, and you used that nifty admin console to change your JVM settings? Are your exceptions going to disappear out of the blue or you have to as well restart the server?! |
It's not my WAS but no, it doesn't need to be restarted. |
Don't delude people or history will lynch you
http://www-01.ibm.com/support/docview.wss?uid=swg21198739
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.base.iseries.doc/info/iseries/ae/tprf_tunejvm_v61.html
| Vitor wrote: |
| yalmasri wrote: |
| Again, why outage? I still have other instances of Broker running |
And is all the traffic being routed away from the downed broker? Even after it's 10 minutes into it's 40 minute start up and the ports are resonsive? Is the traffic diverted away automatically? |
Just for the benefit of the reader, the answer is again no. The machine will be liberated from the cluster and returned back after the water is still. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 21, 2013 5:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
History will lynch me for more than this when the truth comes out. Like I said the WAS here is not my WAS, is administred by a different team & I don't claim more knowledge than the typical WAS end user but they don't restart the WAS when they change the settings. I don't know if they're using the console, the command line or black magic & I defer entirely to the links you posted. I report only what I see.
| Vitor wrote: |
| yalmasri wrote: |
| Again, why outage? I still have other instances of Broker running |
And is all the traffic being routed away from the downed broker? Even after it's 10 minutes into it's 40 minute start up and the ports are resonsive? Is the traffic diverted away automatically? |
Just for the benefit of the reader, the answer is again no. The machine will be liberated from the cluster and returned back after the water is still.[/quote]
"Liberated from the cluster" - is there a runmqsc ALTER QMGR LIBERATE(YES) I've missed???!?!?!?!!?
Seriously, my point is this. If you have either an F5 or a WMQ cluster, the underlying transport protocol will be accepting inbound connections long before all the flows have been successfully restarted to process that traffic.
If what you mean is that a downed broker will have traffic diverted away from it by either reconfiguring the F5 or forcing the queue manager out of the cluster (we must assume here that if the broker is down, the queue manager is unhappy as well) then that a series of manual steps followed by a series of manual steps to reconnect it when normal service is restored. These steps are perfectly feasible but contribute to the additional administrative overhead of banging 700 flows into a single EG I mentioned further up this thread.
I also get the impression you've pretty much made you mind up to do this, given the intensity with which you're defending the position in the face of a lot of advice to the contrary. If so, then I wish you well with it since, as I've stated a few times, it's your choice to make.
You have a perfect right to call the rest of us a load of bald fat idiots who have no idea what we're talking about and don't understand the first thing about WMB, OS processor architecture or the efficient running of a client site. Applying that to my personal position, I'd agree with all but one of those assertions.
(I've managed to lose a lot of weight recently & am no longer fat)
(Or as fat)
(OK - all the assertions)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 21, 2013 8:02 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
There are no specific rules for how many flows is to many flows in an EG. So its understable in wanting to know exactly what will break if you put 700 in one EG.
Not knowing in the least bit what his flows do makes a little more difficult to know for a fact that it won't work for him. What if he does 1 transaction a minute, and each flow is basically just MQInput-->Compute Node w/ 20 lines of basic ESQL-->MQOutput.
Would 700 be workable then?
If not, 600?
500?
299?
143?
Why?
And as soon as you say OK, that number is OK, why are you Ok with that one and not the previous one? This is getting back to the art as much as science comment I made earlier.
In my opinion, the lack of flexibility in implementing potential future granular security and the very likelihood of long Execution Group restart times makes 700 feel plain wrong. But if 350 is better, is it better enough? If you test with 700 and it meets your requirements and SLAs, then you can go with it I suppose. There is no rule or formula that says 700 in one EG is too much.
The collective experience of the mqseries.net borg does know however that the security requirements you know you will never have to deal with will likely introduce themselves the morning after you go live in production with this design, that one day sooner than later your EG will hang and that until you remediate all the flows in that one EG will be impacted, that your EG restart times are almost surely going to be unacceptable when it comes time to recycle that EG in a problem situation where seconds count. But at the same time no one can give you the number below 700 that is all puppy dogs and rainbows. Because no one can give you that number, I understand your desire to stick with 700.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
