| Author |
Message
|
| dkiu |
 Posted: Tue May 02, 2017 1:48 am Post subject: Doubt clear request - HTTP Listener & Embedded listener |
 |
|
Apprentice
Joined: 28 Feb 2013
Posts: 25
|
In one of my project, v7 broker listener have reached their capacity and seems they are failing twice a month.
What changes need to be done at broker end so that existing broker wide listener and its corresponding flow are not impacted while new flows are developed using Embedded Listener concept?? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue May 02, 2017 4:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| dkiu |
| Posted: Tue May 02, 2017 1:11 pm Post subject: |
|
|
Apprentice
Joined: 28 Feb 2013
Posts: 25
|
Thanks this helps, my query was to understand whether EG level embedded listener can be used along with broker wide listener.The link provided says:-
Run below command to deactivate broker wide listener. The execution groups detect this change of status, and use the embedded listener when they are restarted.
mqsichangeproperties MB8BROKER -b httplistener -o HTTPListener -n startListener -v false
If you disable the broker-wide listener in this way, you can configure an execution group to use the same port or ports that the broker-wide listener was using for HTTP,HTTPS, or both. Reusing the port numbers means that you do not have to change your client applications to send messages to a different port number.
To switch to using the embedded listener for a specific execution group,while existing broker listener is still active, use following mqsichangeproperties command
mqsichangeproperties MB8BROKER -e exgroup1 -o ExecutionGroup -n soapNodesUseEmbeddedListener -v true
mqsichangeproperties MB8BROKER -e exgroup1 -o ExecutionGroup -n httpNodesUseEmbeddedListener -v true |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed May 03, 2017 4:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Every time you use an Embedded listener, it must be configured to talk to an unused ip/port configuration.
If you stop the broker listener, and configure an EG embedded listener to use the same ip/port...
Then you can't use the same ip/port for another EG embedded listener.
So unless you want to handle all of your incoming HTTP Traffic with a single EG, then you can't use the same IP/port for every EG.
So if you want a single IP/PORT for all of your incoming HTTP trafficyou can a) use the broker listener, b) handle all of your HTTP input traffic in a single EG, c) configure some kind of http traffic dispatcher (either WAS or apache, as mentioned in the link I posted), or d) configure different clients to use different ip/ports to send traffic to different EGs based on their needs.
Whatever best meets your requirements.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 03, 2017 11:34 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I generally favour giving applications their own port and EG level listener.
However you mentioned the broker wide listener had run out of capacity.
That is a bit vague, there are things to tune such as JVM heap size, max threads and also a parameter that controls how many connection requests can be pending waiting for a thread to become 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 |
|
|
| dkiu |
| Posted: Thu May 04, 2017 5:16 am Post subject: |
|
|
Apprentice
Joined: 28 Feb 2013
Posts: 25
|
@ mqjeff - we don't want to stop the current broker. Existing service should continue to run on current broker whereas any new implementation we are thinking should go for EG embedded listener for all incoming HTTP Traffic. As you said, we can have one EG embedded listener with new IP/PORT and all HTTP traffic can come through this EG .
@Zpat - Yes, you are right. It is already being handled by increasing thread count but what I have been advised it, it is difficult to increase thread count beyond certain limit as number of flows being deployed to production broker are increasing day by day |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 04, 2017 5:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dkiu wrote: |
| we don't want to stop the current broker. |
You're going to have to one day soon, when you move from the out of support v7 broker you're currently using to one of the supported versions.
It might be nice to practice now, rather than during the upgrade.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dkiu |
| Posted: Mon May 08, 2017 4:42 am Post subject: |
|
|
Apprentice
Joined: 28 Feb 2013
Posts: 25
|
Is anyone aware if there is a different timeout response from EG wide listener than broker wide listener. Below is the timeout response in both scenario.
EG WIDE
<text>Timeout. Broker BROKER7 did not provide a response within the specified time interval (10 seconds). The message reached the main flow, but timed out during processing. It was then processed by the timeout flow, but timed out again during processing.</text>
Broker Wide
<text>Timeout. Broker BROKER7 did not provide a response within the specified time interval (10 seconds)</text>
|
|
| Back to top |
|
|
| zpat |
| Posted: Mon May 08, 2017 5:55 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| dkiu wrote: |
| Yes, you are right. It is already being handled by increasing thread count but what I have been advised it, it is difficult to increase thread count beyond certain limit as number of flows being deployed to production broker are increasing day by day |
You can look at increasing the AcceptCount value, but it would seem you need additional EGs or brokers with a http load-balancer in front.
Of course using MQ makes this sort of complexity largely unnecessary,
_________________
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 |
|
|
|
|
