| Author |
Message
|
| Dave Ziegler |
 Posted: Wed Feb 18, 2015 11:43 am Post subject: |
 |
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| mgk wrote: |
If you don't want this behaviour, you can either specify a specific "fixed" port per EG, that will cause the EG start to fail if it's not available |
Is this the command being referenced here?
| Code: |
mqsichangeproperties IB9NODE -e exgroup1 -o HTTPSConnector -n explicitlySetPortNumber -v 7777 |
|
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Feb 19, 2015 5:14 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
That's the one. Note you have the choice between HTTPConnector and HTTPSConnector to set respectively the HTTP and HTTPS ports.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Thu Feb 19, 2015 2:43 pm Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| Can someone explain to me what use case dynamic port assignment addresses? If I stand up an Integration Service (SOAP service) and it is hosted at http://localhost:7800/MyService by default, and then [whatever] happens and a broker restart changes this to 7801 because 7800 has been hijacked... what happens to all my flows or applications depending on this service being hosted at the original URL, won't they fail to locate the SOAP service? Is there some sort of dynamic service discovery that can be implemented that I'm not considering? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Feb 19, 2015 10:29 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
In all the systems where we have used SOAP in more than one Execution Group then we explicitly set the SOAP PORT for that EG.
The hijacking you mention could be that EG1 starts faster than EG0 and nicks port 7800 from EG0. Explicitly set the port and this can be forgotten.
All it takes is one line in your Create EG script.
my template Create Broker scripts automatically sets a port for HTTP and HTTPS on each EG as it is created even if no SOAP flows are going to be deployed. It costs nothing be a couple of seconds when creating an EG.
Cheap at half the price.
 Slap on wrist for using EG's and Broker. I'm afraid that this old dog will use them rather than the IIB NewSpeak mumblywhatsitcalledtoday language.
_________________
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 |
|
|
| orman |
| Posted: Fri Feb 20, 2015 1:54 am Post subject: |
|
|
Apprentice
Joined: 08 Aug 2013
Posts: 40
|
| mgk wrote: |
The default for the SOAP nodes is to use the Execution Group listener. This means that each EG will get it's own port from the port range. All SOAP Input nodes in the same flow will use the port for that EG, and the port belongs to the EG, not any particular flow.
|
| mgk wrote: |
Summary:
| Code: |
Default Can Use
SOAPInput Per-EG Per-Broker
HTTPInput Per-Broker Per-EG |
I hope that helps a little.
Kind regards, |
Those are the defaults, as it quoted here.
You can change it with the soapNodesUseEmbeddedListener and httpNodesUseEmbeddedListener commands to make node to listen the embedded (EG) HTTP listener or to the broker-wide HTTP listener
For more information you can read on info-center or here:
https://esbteamil.wordpress.com/2015/01/05/working-with-soaphttp-node-in-broker/ |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Fri Feb 20, 2015 8:36 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
I understand the defaults, and I understand the information MGK posted. The question is: Can someone explain to me what use case dynamic port assignment addresses?
I just want to make sure I understand the default behavior before I go changing things. At present, I don't know why it would be desirable for the ports to change automagically on my SOAP endpoints. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 20, 2015 9:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Dave Ziegler wrote: |
I understand the defaults, and I understand the information MGK posted. The question is: Can someone explain to me what use case dynamic port assignment addresses?
I just want to make sure I understand the default behavior before I go changing things. At present, I don't know why it would be desirable for the ports to change automagically on my SOAP endpoints. |
It's not terribly clear to me either. I ssupect it's fundamentally a property of the underlying engine, and that the underlying engine was built that way to make it easier to drop in and run without complex config of the network layer before hand.
And enabled so that multiple EGs would start up without actually stepping on each other. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 20, 2015 9:35 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| mqjeff wrote: |
It's not terribly clear to me either. I ssupect it's fundamentally a property of the underlying engine, and that the underlying engine was built that way to make it easier to drop in and run without complex config of the network layer before hand.
And enabled so that multiple EGs would start up without actually stepping on each other. |
And the point of the ports becoming "sticky" after having been used was to ease admin?.
Like most old-timers I like to make the ports predictable. Which means setting them explicitly. This will guarantee that if a port gets hijacked I have to find the offender and fix the situation before the broker works correctly again..., but I expect those problems to shake out in test/qa.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Feb 26, 2015 1:21 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Applications need predictable port numbers - so fix them.
What I then do is set the dynamic range to start from just above the last port number that I fixed.
Then if another EG grabs a port - it will be immediately above my fixed set - when I notice this, I will fix it at the same value, then raise the dynamic range to start one higher.
Allocating a fixed port to each EG, regardless of whether they plan to use it is, I suppose a better practice - but I prefer to keep all ports unique over the entire estate, which sort of reduces the numbers available.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| mgk |
| Posted: Thu Feb 26, 2015 8:44 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1638
|
The reason for a dynamic range is that you can give your range to a load balancer that sits in front of WMB/IIB and sprays the work across a set of identical EGs (servers). For this scenario, unless you have affinity you do not care which request goes to which EG. Of course this scenario does not work for everyone, but we could not address this easily without the dynamic range of ports as you can easily add or remove EGs without having to change the load balancer's configuration. The reason we have "sticky" ports as well as "fixed ports" in addition to the dynamic range is to address a broader range of scenarios.
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Feb 26, 2015 10:14 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
That load-balancer scenario doesn't really make sense in IMHO.
The last thing you want is to start sending BigIP requests to an unrelated EG that just so happens to have deployed a http or soap node without a fixed port.
It would be a (massive production) accident waiting to happen. Only really acceptable if dedicating a broker to one application.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| mgk |
| Posted: Fri Feb 27, 2015 6:42 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1638
|
Of course the unrelated EG scenario would be a bad idea, but if you want to "auto scale" by simply adding (or stopping) identical EG's then it works very well. YMMV 
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
|
|
