| Author |
Message
|
| railbroker1 |
 Posted: Wed Apr 17, 2013 10:28 pm Post subject: WMB as TCP/IP Socket Server, socket connection gets killed |
 |
|
Newbie
Joined: 28 Mar 2013
Posts: 8
|
Hi!
We have to integrate some clients via TCP/IP Sockets. Our WMB 7.0.0.5 acts as SocketServer. The Client initiates the connection with a kind of log on handshake (ClientToServer LogOn Msg -> ServerToClient LogOn ACK Msg -> ServerToClient LogOn Msg -> ClientToServer LogOn ACK Msg). The socket connection must then be kept open (until a timeout or an error occurs). Client and server then exchange messages asynchronously over the open socket connection. To avoid timeouts, the client periodically sends a heartbeat PING message. We created a flow with TCP/IP Nodes and applied the required protocol rules: TCP/IP ServerInputNode -> LogOn Subflow -> Save LoggedIn State -> TCP/IP ServerReceive Node "Listen" -> Process Message -> MQ OUT Queue -> TCP/IP ServerReceive Node "Listen" ... (Kind of loop). A second subflow Listens to a MQ IN Queue and sends Messages to the Client: MQ IN Queue -> Process Message -> TCP/IPServerOutputNode. All of the TCP/IP Nodes are configured to listen to the same port. All TCP/IP Nodes are configured not to close the connection and leave the input and output streams unchanged (no reservation). This scenario works fine so far. But we run into a strange problem: Everytime when the client has sent exactly 12 messages the socket connection gets closed by the server side. At the same time the debug session of the WMB Toolkit gets killed. No error logs. It not seems to be a timeout issue, because the connection stays open as long as we want - until a certain amount of messages a exchanged. We have tested that with different Socket Clients remote and on the same machine where the WMB runs (to avoid infrastructure effects) -> same behavior in all tests. We then created a simple test flow (without logon handshake, etc) which only listens on a TCP Socket and echos the received messages to the client and returns in a loop back to the TCP/IP Server Receive node. The same behavior here: After a certain amount of messages exchanged, the socket connection gets killed by the server, if no ore only some messages are exchanged, the connection stays open.
Do you guys have an idea? May there be a problem with the "long running" flow because of the loop to the TCPServer Receive Node? Is this flow pattern for a TCP/IP Server not applicable to the WMB?
Thanks a lot for your help! |
|
| Back to top |
|
 |
| McueMart |
| Posted: Thu Apr 18, 2013 12:26 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Im not sure how much useful information you will get but try running a User Trace while causing the connection to close. If you get anything useful post it here. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Apr 18, 2013 12:30 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| TCP/IP ServerInputNode -> LogOn Subflow -> Save LoggedIn State -> TCP/IP ServerReceive Node "Listen" -> Process Message -> MQ OUT Queue -> TCP/IP ServerReceive Node "Listen" ... (Kind of loop) |
I may be misunderstanding your flow, but every time I hear 'message flow' and 'loop' in the same sentence I am filled with a sense of impending disaster.
If your message flow really does contain a loop then you should try very hard to redesign it ( and/or the systems that it interacts with ) in such a way as to avoid a loop. |
|
| Back to top |
|
|
| railbroker1 |
| Posted: Thu Apr 18, 2013 2:55 am Post subject: |
|
|
Newbie
Joined: 28 Mar 2013
Posts: 8
|
@McueMart:
Thank you for the hint! Unfortunately we can't find anything useful about the unexpected closing of the socket connection in the debug level user trace. It seems, that an internal ressource (perhaps somwhere around the wmb tcp socket connection manager) gets exhausted and leads to this unexpected stream loss. Just a guess...
@kimbert:
Fully agree! This "strange" loop in the flow was the only way we figured out so far to keep the socket connection and input/output streams open and same after the initial handshake for the async bidirectional message exchange between client and server. Redesigning the external communication partner side is no option :-/
Are there perhaps other ways to achieve this desired behaviour in WMB? We thought about a Handshake Flow which sets a global "LoggedIn" Flag. Based on that flag we can route in another flow further inbound and outbound messages over the established socket connection without a loop in the flow. But our tests with different config settings with and without stream reservation in the TCP/IP Nodes were not sucessful so far....
Thanks for your help! |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Sun Apr 21, 2013 6:41 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
What kimbert is telling you is "Don't create circular looping message flows. "
Have you attended the training class in which they specifically call out this issue? If you have not attended, why not?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| railbroker1 |
| Posted: Mon Apr 22, 2013 10:33 pm Post subject: |
|
|
Newbie
Joined: 28 Mar 2013
Posts: 8
|
Hi lancelototlinc,
Thank you for your answer. Yes, i did attend the training class, and yes, as already mentioned it's clear to me that loops in WMB flows are not feasible. And no, WMB acting as TCPSocketServer was unfortunatreley not part of the IBM Training class. I can not imagine, that it is not possible to design in WMB a simple TCPSocketServer interface with a handshake upfront and a long running bidirectional SocketConnection with a TCPSocket Client. I know it's old fashioned style - but non invasive integration of legacy systems should in my point of view not be a problem for such an integration platform as WMB.
That's why I'm asking this forum full of experienced experts 
Thanks and best regards. |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Apr 23, 2013 12:33 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
One thing worth trying is to remove the 'loop' from your flow. As others have pointed out this is pretty much always a bad design within a flow.
Instead of a loop, you would have something like this:
| Code: |
| TCP/IP ServerInputNode -> LogOn Subflow -> Save LoggedIn State -> ComputeNode_Keep_Propagating -> TCP/IP ServerReceive Node "Listen" -> Process Message -> MQ OUT Queue |
The node ComputeNode_Keep_Propagating would have a simple while loop in it which keeps Propagating out its Output terminal.
Can you explain more clearly why you need this flow to be a long running thing (i.e. what does this Handshake need to establish?). Normally very long running flows are seen as a bad design - One reason being that you wont be able to stop your flow (easily)! |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Apr 23, 2013 12:42 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Sometimes you want to keep a connection open for a long period.
In these cases I generally use another flow to send a 'keepalive' message to the flow with the TCP/IP connection open every (say) two minutes. This is sent over the link keeping it from timing out. no loops or endless propagates needed, just a flow that is responsible for sending out all sorts of repeat times message.
_________________
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 |
|
|
| railbroker1 |
| Posted: Tue Apr 23, 2013 2:41 am Post subject: |
|
|
Newbie
Joined: 28 Mar 2013
Posts: 8
|
@McueMart and @smdavies99
| Quote: |
| Can you explain more clearly why you need this flow to be a long running thing (i.e. what does this Handshake need to establish?). |
| Quote: |
| In these cases I generally use another flow to send a 'keepalive' message to the flow with the TCP/IP connection open |
We have to follow this scenario, defined in an interface contract according to a railway business specific communication protocol:
- Our WMB acts as SocketServer
- Partner System is SocketClient
- Partner System (SocketClient) opens connection and "logs in" with the simple protocol handshake
- When logged in, Partner System sends async Realtime Messages to WMB
- WMB System sends async Realtime Messages to Partner System
--> Both over the same socket connection
- Partner System sends ping / keep alive messages periodically to avoid to reach the defined socket timeout
- Socket connection should then only get closed, when an error occurs.
Our main Problem:
(Without loop in flow)
- Once the handshake is successful and the first message is published at the end of the flow, the socket connection remains open. OK
- When the next message is send from Client to WMB over the same still open socket connection, the outbound stream of the socket seems not to be the same any more --> Client can't receive ACK from Server PROBLEM
- Async Data Messages from WMB to Client can not be sent either. PROBLEM
(With loop in flow)
- Once the handshake is successful and the first message is published at the end of the flow, the socket connection remains open. OK
- Messages and ACKs can be send and received in both directions and the same socket connection. Inpout and Outputstream seem to be the same now. OK
- After sending a certain amount of messages from Client to WMB the socket gets killed unexpectedly. PROBLEM
- Bad flow design PROBLEM
We already tried:
- Different combinations of input/outputstream modification settings of the TCP Nodes, so that the WMB Socket Management may use the same socket connection over multiple flow runs - with no success.
What we now want to figure out:
- How can we get WMB to act as SocketServer and reuse same Socket (Same InputStream and same OutputStream) for multiple flow runs without a flow loop. (The connection keeps already open during multiple flow runs, the missing bit is the reuse of the input and outputstreams)
As next step, we will try McueMart's tip with the little loop in the compute node.
Thank you for your help! |
|
| Back to top |
|
|
| railbroker1 |
| Posted: Wed Apr 24, 2013 4:54 am Post subject: |
|
|
Newbie
Joined: 28 Mar 2013
Posts: 8
|
Problem is solved now. This is the solution:
1.) Removed the TCPServerReceiver ("Listen") Node after the handshake from flow. This one required the looping. Now there is no loop any more.
2.) Configured every TCP Node (Request/ID location) to reuse the Connection ID created by the initial TCPServerInput Node in the local environment ($LocalEnvironment/TCPIP/Input/ConnectionDetails/Id)
Now the socket communication works as required 
Nonetheless, thank you for your input! |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Apr 24, 2013 5:02 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| This is a good day. Two threads about loops in message flows. Both resolved using standard facilities and no loops. |
|
| Back to top |
|
|
| railbroker1 |
| Posted: Wed Apr 24, 2013 5:04 am Post subject: |
|
|
Newbie
Joined: 28 Mar 2013
Posts: 8
|
|
| Back to top |
|
|
|
|
