| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| http listener and netstat |
« View previous topic :: View next topic » |
| Author |
Message
|
| duffMan |
 Posted: Wed Dec 03, 2008 3:11 pm Post subject: http listener and netstat |
 |
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
Any netstat (AIX) experts out there?
One of our two production mqsi v6.0 brokers decided that it didn't want to do anymore http work. We'll actually the result of the http trace shows that it's waiting for something to do, but apparently doesn't get any data.
I've hit both ip/ports directly with a browser. The broken one gives me a http 400 error "bad request". The working one gives me a soap fault...which is a good thing ... in this case.
I then ran netstat and found that the broken server shows a bit more data in the output than the working one. Anyone know how to interpret this data? I see 7080 sprinkled through which is the port, but what are the other values. The word "stream" doesn't look so good either. 
BROKEN BROKER
$ netstat -an | grep 7080
tcp 0 0 *.7080 *.* LISTEN
710ddc08 stream 0 0 0 71097080 0 0
71097080
71827080
NOT SO BROKEN BROKER
$ netstat -a | grep 7080
tcp 0 0 *.7080 *.* LISTEN
I can't simply recycle the broker or server in the middle of the business day and I've tried starting and stopping flows that have http input nodes, tried killing specific DataFlowEngine processes...all to no avail.
I'd like to understand the problem rather than turning a blind eye and 'accidentaly' tripping over the power cord to the server. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Dec 03, 2008 3:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Are you certain that there is no contention for the broker at port 7080?
You will be able to see that when the broker is down. If you still see the LISTEN with netstat -an for that port but the corresponding biphttplistener process id down you have contention.
You need to find out which process is in contention. You will have to make a choice. Either change the port of the offending process/application or change the port for the http listener of the broker. How to is in the doc. (see infocenter)
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| duffMan |
| Posted: Wed Dec 03, 2008 5:58 pm Post subject: |
|
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
when the broker is down this is what netstat says,,
$ netstat -na | grep 7080
710ddc08 stream 0 0 0 71097080 0 0
71097080
71827080
It doesn't indicate something is LISTENING, but there is still evidence of something going on at port 7080. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Wed Dec 03, 2008 7:58 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| duffMan wrote: |
when the broker is down this is what netstat says,,
$ netstat -na | grep 7080
710ddc08 stream 0 0 0 71097080 0 0
71097080
71827080
It doesn't indicate something is LISTENING, but there is still evidence of something going on at port 7080. |
No, this is not evidence that something is going on at port 7080. This is evidence that grep can print unrelated lines that happen to contain the string "7080".
netstat displays network statistics, not just for internet connections, but for other network objects too, such as UNIX domain sockets, (used for streams, datagrams, fifos, etc.)
To narrow your grep output to just TCP port 7080 activity, you might try something like:
| Code: |
| netstat -na | grep '^tcp.*\.7080 ' |
If the broker is down, and nothing is listening on that port, then it doesn't look like port contention is the problem.
If the client receives an HTTP 400 "Bad Request", I would think that would show up in an http trace. Perhaps there's something wrong with the URL? |
|
| Back to top |
|
|
| duffMan |
| Posted: Wed Dec 03, 2008 9:25 pm Post subject: |
|
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
you are right... about the grep... an oversight on my part.
we ended up recycling the server and poof the problem was gone.
recycling the broker didn't do the trick.
the http trace did not show show any errors. It seemed as though message broker (the biphttplistener process) never received data.
... so not sure what the problem was, not what my manager wants to hear...but oh well.
thanks for the suggestions. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
