| Author |
Message
|
| MartynB |
 Posted: Tue Feb 19, 2008 9:05 am Post subject: |
 |
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
| We have also tried different port ranges with my TCP/IP tool however we stil get the issue. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Feb 19, 2008 9:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Does the Python script and Netcat establish a long lasting connection? Or a single open/close socket?
I suspect you're seeing issues because the Windows network stack is deciding that the connection has been open "too long" and is thus deserving to be killed.
I.e. that your connection is exceeding the system level KeepAlive.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| MartynB |
| Posted: Tue Feb 19, 2008 9:21 am Post subject: |
|
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
I believe the python script and netcat keep a single connection open. I've looked at the python script and it does certainly programmatically appear to work this way. The logic appears to be exactly the same way as from my TCP/IP tool (which is just a very lightwieght wrapper around the windows APIs).
Believing this to be related to a timeout due to lack of traffic we had also modified the python script to behave in the same way as MQ and how we used my TCP/IP tool. That being: send/receive, sleep for 150 seconds, repeat.
On my tool this consistently reproduced the problem. The python script maintained a consistent connection.
We've also looked as some of the registry settings on the errant server (as per http://support.microsoft.com/kb/314053 ) however there seems to be nothing related to keepalive that seems to be different to a working server. The only thing that seems small is the lease setting however I don't believe this to be pertinent to this particular problem (it's some kind of dhcp configuration) nor would it explain why python and netcat work ok.
Thanks for your comments - keep 'em coming if you have any more useful ideas. |
|
| Back to top |
|
|
| MartynB |
| Posted: Tue Feb 19, 2008 9:27 am Post subject: |
|
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
| If anyone can think of a way whereby I can categorically prove this is not an issue with MQ and is TCP/IP related please let me know. |
|
| Back to top |
|
|
| MartynB |
| Posted: Tue Feb 19, 2008 9:58 am Post subject: |
|
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
Ok - I've managed (finally) to get the CSD installed after much head scratching/frustration. Interestingly it is not displayed in MQ Explorer, you have to look in the registry or dspmqver to verify this.
Now two of the machines are running 6.0.2.1.
When I bring up the sender channel using this CSD and.... |
|
| Back to top |
|
|
| MartynB |
| Posted: Tue Feb 19, 2008 10:20 am Post subject: |
|
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
...the channels from windows to windows remain UP!!! 
The disconnection interval elapses and they come down cleanly! 
From unix to windows the channel comes up and disconnects cleanly!!!!  
I can only think that this fix pack has applied something to work around the problem but it was not MQ 6.0.0.0 that was at fault because this version is installed and working in another environment. I'm also led to believe that MQ 6.0.0.0 was not at fault because of the problems I experienced over IP without MQ.
I think we need a proper steer from IBM as to which CSD we should be running - given that they specifically gave me V6.0.0.0. MQ version 6.0.0.0 does not seem compatible with this environment. Tommorrow I will see if my tool over IP seems to function correctly now. I.e. Does the CSD actually do anything to the windows TCP/IP configuration?
Thanks to all who posted.  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 19, 2008 12:41 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| MartynB wrote: |
| I think we need a proper steer from IBM as to which CSD we should be running - given that they specifically gave me V6.0.0.0. |
Do you expect them to say anything other than the latest one (6.0.2.3)? 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Feb 19, 2008 12:42 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I believe tolerance for win64 is built into later FPs.
It was not available in v6.0.0.0 - which is why you needed a custom version.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 19, 2008 2:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
I believe tolerance for win64 is built into later FPs.
It was not available in v6.0.0.0 - which is why you needed a custom version. |
| MartynB wrote: |
| I can only think that this fix pack has applied something to work around the problem but it was not MQ 6.0.0.0 that was at fault because this version is installed and working in another environment. I'm also led to believe that MQ 6.0.0.0 was not at fault because of the problems I experienced over IP without MQ. |
Personally I wouldn't want to run anything below 6.0.1.1
And anyways upgrade to the latest !!! (6.0.2.3)
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
