| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Web Services with SOAPInputNode port issue |
« View previous topic :: View next topic » |
| Author |
Message
|
| ImSoTired |
 Posted: Thu Dec 04, 2008 8:15 pm Post subject: Web Services with SOAPInputNode port issue |
 |
|
Novice
Joined: 17 Apr 2007
Posts: 20
Location: Lima, Perú
|
Hi experts  ,
I have this behavior in my broker domain (with MQ v6.0.2.3, MB v6.1.0.2) with a ConfigMgr and a single broker (called WMBROKER) in a AIX box (v5.3 ML 5), both share a queue manager. I have 3 execution groups called EG_01, EG_02 and EG_03. When i deployed three bar files (each bar file contains a flow that implements a web service with an SOAPInputNode) in each execution group (01.bar into EG_01, 02.bar into EG_02 and 03.bar into EG_03), the httplistener begins to listen in a diferent port consecutively!! why?? i suposed that port 7800 is the default port for all flows that contains an SOAPInputNode, in the same way with the port 7080 for HTTPInputNode... i don't understand this issue and i don't find anything in the documentation for this.
An extract to syslog of the AIX after deploy:
An extract to syslog of the AIX:
Dec 4 22:47:29 myserver user:info WebSphere Broker v6102[1487042]: (WMBROKER.EG_01)[8996]BIP3132I: The HTTP Listener has started listening on port '7800' for 'http' connections. : WMBROKER.ddf222fb-1d01-0000-0080-af39c027aba5: /build/S610_P/src
/DataFlowEngine/NativeTrace/ImbNativeTrace.cpp: 816: TomcatInstanceManager::startTomcatIfNecessary: DynamicSubscriptionEngine
: DynamicSubscriptionEngine
Dec 4 22:47:49 myserver user:info WebSphere Broker v6102[1265806]: (WMBROKER.EG_02)[6940]BIP3132I: The HTTP Listener has started listening on port '7801' for 'http' connections. : WMBROKER.bcf126fb-1d01-0000-0080-af39c027aba5: /build/S610_P/sr
c/DataFlowEngine/NativeTrace/ImbNativeTrace.cpp: 816: TomcatInstanceManager::startTomcatIfNecessary: DynamicSubscriptionEngin
e: DynamicSubscriptionEngine
Dec 4 22:48:12 myserver user:info WebSphere Broker v6102[3719188]: (WMBROKER.EG_03)[6940]BIP3132I: The HTTP Listener has started listening on port '7802' for 'http' connections. : WMBROKER.315e27fb-1d01-0000-0080-af39c027aba5: /build/S610_P/sr
c/DataFlowEngine/NativeTrace/ImbNativeTrace.cpp: 816: TomcatInstanceManager::startTomcatIfNecessary: DynamicSubscriptionEngin
e: DynamicSubscriptionEngine
When i delete the flows from the execution flows:
Dec 4 23:11:13 myserver user:info WebSphere Broker v6102[3719188]: (WMBROKER.EG_01)[6940]BIP3133I: The HTTP Listener has stopped listening on port '7800' for 'http' connections. : WMBROKER.315e27fb-1d01-0000-0080-af39c027aba5: /build/S610_P/sr
c/DataFlowEngine/NativeTrace/ImbNativeTrace.cpp: 816: TomcatInstanceManager::stopTomcatIfStarted: DynamicSubscriptionEngine:
DynamicSubscriptionEngine
Dec 4 23:11:34 myserver user:info WebSphere Broker v6102[1265806]: (WMBROKER.EG_02)[6940]BIP3133I: The HTTP Listener has stopped listening on port '7801' for 'http' connections. : WMBROKER.bcf126fb-1d01-0000-0080-af39c027aba5: /build/S610_P/sr
c/DataFlowEngine/NativeTrace/ImbNativeTrace.cpp: 816: TomcatInstanceManager::stopTomcatIfStarted: DynamicSubscriptionEngine:
DynamicSubscriptionEngine
Dec 4 23:11:50 myserver user:info WebSphere Broker v6102[1487042]: (WMBROKER.EG_03)[8996]BIP3133I: The HTTP Listener has stopped listening on port '7802' for 'http' connections. : WMBROKER.ddf222fb-1d01-0000-0080-af39c027aba5: /build/S610_P/src
/DataFlowEngine/NativeTrace/ImbNativeTrace.cpp: 816: TomcatInstanceManager::stopTomcatIfStarted: DynamicSubscriptionEngine: D
ynamicSubscriptionEngine
Please, can anyone help me??  i don't have set any especial configuration in the broker. 
Thanks!  |
|
| Back to top |
|
 |
| keenlearner |
| Posted: Thu Dec 04, 2008 9:40 pm Post subject: |
|
|
Acolyte
Joined: 24 Aug 2006
Posts: 62
|
This is due to the fact that the SOAP messages port are defined at execution group level and HTTP port are defined at Broker Level.
Hence we have only one port for HTTP communocations, default being 7080. For Soap over http or https each execution group has individual port number. Default is 7800 and it keeps incrementing by one.
You can also define you custom port number.
Now why they have http port at broker level and soap over http at executin group level is matter of product design. Will wirte again if get some thing on it. |
|
| Back to top |
|
|
| ImSoTired |
| Posted: Tue Dec 09, 2008 8:27 am Post subject: |
|
|
Novice
Joined: 17 Apr 2007
Posts: 20
Location: Lima, Perú
|
Thanks for your help keenlearner,
i'll must set the SOAP port for each execution group. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 14, 2009 11:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| keenlearner wrote: |
Hence we have only one port for HTTP communocations, default being 7080. For Soap over http or https each execution group has individual port number. Default is 7800 and it keeps incrementing by one.
You can also define you custom port number.
|
So the 1st EG with a Soap Node gets 7800, and the next EG with a Soap Node gets 7801?
Do those EGs then keep those port assigments forever, or when the Broker restarts each EG with a Soap Node races for a port 7800 or higher?
Or do I have to use mqsichangeproperties to assign port #s explicitly so EG1 with SoapFlow1 always gets 7800, EG2 with SoapFlow2 always uses 7801, etc.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Jan 14, 2009 1:13 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Hi.
| Quote: |
| Do those EGs then keep those port assigments forever |
Yes, the ports are 'sticky' and an E.G. will try to come up on the port it last used. However if that port is in use it will then take the first free port in the range.
| Quote: |
| Or do I have to use mqsichangeproperties to assign port |
You can do this if you wish. The difference is that if the E.G. finds an explicitly set port in use it will then fail to come up with an error message say essentially "port in use"
So using mqsichangeproperties you can change the port-range as well which allows you to set the range of ports for SSL and non-ssl Soapnode connections.
One of the reasons for having a port per E.G. model is that is allows you to "Front" the E.G.s with a network load balancer which can "spray" traffic across a defined port-range (E.G.'s).
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 |
|
|
| PeterPotkay |
| Posted: Wed Jan 14, 2009 2:57 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Hi mgk,
| mgk wrote: |
Yes, the ports are 'sticky' and an E.G. will try to come up on the port it last used.
|
A somewhat important piece of info missing from the Info Center. Thanks!
| mgk wrote: |
However if that port is in use it will then take the first free port in the range.
|
And so does that then become the new sticky port? Or the next EG restart has it using the original port?
| mgk wrote: |
One of the reasons for having a port per E.G. model is that is allows you to "Front" the E.G.s with a network load balancer which can "spray" traffic across a defined port-range (E.G.'s).
|
That is true, but lets assume each unique Soap Node flow lives in only one EG. It may have additional instances in that one EG, but it exists in only that one EG. And other Soap Node Flows live in other EGs, or maybe even in that same EG.
For each EG that has a Soap Node, I have to create a unique network balancer URL aimed at that specific port. That is a (small) pain compared to http nodes, where the one listener services the whole broker, and one URL is enough for port 7080. Not a big deal.
| mgk wrote: |
Quote:
Or do I have to use mqsichangeproperties to assign port
You can do this if you wish. The difference is that if the E.G. finds an explicitly set port in use it will then fail to come up with an error message say essentially "port in use"
|
The entire EG fails to come up? Or just the Soap Nodes in that EG? Either way, will it continue to retry?
If the load balancer URLs are aimed at port 7801, for example, across the same EG in 3 different Brokers, what should we do? Use explicit ports, which means the URLs will always be valid, although the Soap Flows in the EG (or maybe the whole EG!) maybe N/A if something grabbed that port? Or use sticky ports, in which case the EG may come up on a new port, and perhaps be stuck on that new port going forward, which is bad, since I then have to recreate URLs or explicitly try to reassign the port..
I guess I need to know the behaviour in all of the above scenarios before I can choose dynamic sticky port assigments or explicit.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| antonio |
| Posted: Thu Jan 15, 2009 2:51 pm Post subject: Number of SOAP based message flows in an execution group? |
|
|
Newbie
Joined: 19 Jan 2006
Posts: 1
Location: India
|
Hey Peet,
How many SOAP Input Node based message flows can i have in a single execution group of a broker?
| PeterPotkay wrote: |
| Hi mgk, |
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 15, 2009 3:58 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| As many as you have MQSI_THREAD_STACK_SIZE for. |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Jan 20, 2009 3:48 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Hello.
| Quote: |
| And so does that then become the new sticky port |
Yes
| Quote: |
| The entire EG fails to come up? |
No
| Quote: |
| Or just the Soap Nodes in that EG? |
Yes - Just the HTTPConnector in that DFE - and an error message is reported.
| Quote: |
| Either way, will it continue to retry? |
No - It acts just like the existing HTTPNode HTTPListener (biphttplistener) - if that fails to get its assigned port, it too will not come start the connector and report an error message - and neither of them retry in "sticky port" mode.
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 |
|
|
| PeterPotkay |
| Posted: Tue Jan 20, 2009 6:05 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Regarding HTTP Connector if you don't explicitly assign it and let it pick the first one over 7800
| mgk wrote: |
| Quote: |
| Do those EGs then keep those port assigments forever |
Yes, the ports are 'sticky' and an E.G. will try to come up on the port it last used. However if that port is in use it will then take the first free port in the range.
|
If your clients are all aimed at the port it was developed at, lets say 7801, of what use is it for the HTTP Connector to come up on 7802 if none of the clients are aimed at 7802?
I struggle with why you would ever want this behaviour and not always use mqsichangeproperties to explicitly tie the EG's HTTP Connector to the one port all the clients know it to live on.
| Quote: |
Quote:
Either way, will it continue to retry?
No - It acts just like the existing HTTPNode HTTPListener (biphttplistener) - if that fails to get its assigned port, it too will not come start the connector and report an error message - and neither of them retry in "sticky port" mode.
|
Wouldn't it be beneficial and relativily easy to add retry logic to the listeners? Perhaps the thing that has the port only had it for a few seconds and now that the port is free, why not have the Broker automatically recover? (I've often wondered the same thing about MQ's Listeners as well.)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 22, 2009 10:16 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Opened a PMR and spoke with MGK and here's the scoop.
If you explicitly set the port # for the EG's HTTP Connector using the mqsichangeproperties, that EG will only ever use that port # for it's Soap Input Nodes. If that port is in use by something else at Execution Group start up time, the HTTP Connector will fail. Any Soap Input Nodes in that EG will be out of commision. The HTTP Connector will not attempt to retry. To restart it and have it attempt to open the port again, you will have to restart the Execution Group (i.e. restart the Broker), or redeploy one flow with a Soap Input node to the running EG.
If you DO NOT set the port # for the EG's HTTP Connector using the mqsichangeproperties, that EG will grab the first open port above 7799 the first time that it starts with a Soap Input Node. That becomes its "sticky port"; it will always attempt to grab that port everytime the EG starts up. If it finds that port in use, it will try the next open port above the one it just tried, all the way up to potentially 7842 (*see below), until it finds one. Assuming it does, that new port then becomes its new sticky port and it will use that one going forward.
I asked how this is beneficial if the clients are coding their URLs at a specific port. Why would you want to introduce the possability of that port changing? The idea behind this is increased availability, should the initial sticky port be taken by who-knows-what. The HTTP Connector will grab the next available port and the Soap Nodes will start. The clients should not aim directly at the port # initially assigned dynamically by the Broker. They should aim at a Network Dispatcher (Load Balancer) that is configured to try the various ports on the Broker sequentially. Should the "sticky" port change to another, the clients are non the wiser and life goes on.
*Use the httpConnectorPortRange parm via the mqsichangeproperties command to set a specific range between 7800-7842 that the sticky port can choose from. This way you can give a range of 6 or so ports to Execution Group 1, another range of 6 to choose from for Execution Group 2, etc, etc. The odds that all 6 are grabbed by some mysterious process should be low enough to not matter.
Regarding the biphttplistener for plain HTTP Input nodes, I am opening a request to add retry logic to it, so that if it finds its one port (7080 by default) used by something else, it will periodically retry. Who knows, it might get lucky and find it free, restoring service automagically versus today's situation where it is down for good even if the port opens up until you restart the Broker. The engineer that wrote the HTTP Connector is the same that wrote the HTTP Listener, so maybe they would even consider adding the same floating sticky port logic as an option.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 23, 2009 3:18 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
Opened a PMR and spoke with MGK and here's the scoop.
If you explicitly set the port # for the EG's HTTP Connector using the mqsichangeproperties, that EG will only ever use that port # for it's Soap Input Nodes. If that port is in use by something else at Execution Group start up time, the HTTP Connector will fail. Any Soap Input Nodes in that EG will be out of commision. The HTTP Connector will not attempt to retry. To restart it and have it attempt to open the port again, you will have to restart the Execution Group (i.e. restart the Broker), or redeploy one flow with a Soap Input node to the running EG. |
Disagree with the comment restart the broker. Although restarting the broker will achieve what you are looking for, the i.e. part implies that to restart the EG you would have to restart the broker... and this is what I am protesting about. What about mqsireload or just plain stop and restart the EG or just stop and start the flow with the soapnode ?
| PeterPotkay wrote: |
If you DO NOT set the port # for the EG's HTTP Connector using the mqsichangeproperties, that EG will grab the first open port above 7799 the first time that it starts with a Soap Input Node. That becomes its "sticky port"; it will always attempt to grab that port everytime the EG starts up. If it finds that port in use, it will try the next open port above the one it just tried, all the way up to potentially 7842 (*see below), until it finds one. Assuming it does, that new port then becomes its new sticky port and it will use that one going forward.
I asked how this is beneficial if the clients are coding their URLs at a specific port. Why would you want to introduce the possibility of that port changing? The idea behind this is increased availability, should the initial sticky port be taken by who-knows-what. The HTTP Connector will grab the next available port and the Soap Nodes will start. The clients should not aim directly at the port # initially assigned dynamically by the Broker. They should aim at a Network Dispatcher (Load Balancer) that is configured to try the various ports on the Broker sequentially. Should the "sticky" port change to another, the clients are non the wiser and life goes on.
*Use the httpConnectorPortRange parm via the mqsichangeproperties command to set a specific range between 7800-7842 that the sticky port can choose from. This way you can give a range of 6 or so ports to Execution Group 1, another range of 6 to choose from for Execution Group 2, etc, etc. The odds that all 6 are grabbed by some mysterious process should be low enough to not matter.
Regarding the biphttplistener for plain HTTP Input nodes, I am opening a request to add retry logic to it, so that if it finds its one port (7080 by default) used by something else, it will periodically retry. Who knows, it might get lucky and find it free, restoring service automagically versus today's situation where it is down for good even if the port opens up until you restart the Broker. The engineer that wrote the HTTP Connector is the same that wrote the HTTP Listener, so maybe they would even consider adding the same floating sticky port logic as an option. |
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 23, 2009 11:53 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Broker restart is overkill. mqsireload is the correct choice. Stopping and starting the flow is apprently not enough, although redeploying at least one is.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jan 14, 2011 5:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
What is the actual mqsichangeproperties command to set the SOAP port for an execution group.
Something like this?
mqsichangeproperties <brkname> -e <egname> -o HTTPConnector -n explicitlySetPortNumber -v <nnnn> |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jan 14, 2011 6:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
