| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Complex TCPIP Flow |
« View previous topic :: View next topic » |
| Author |
Message
|
| PEPERO |
 Posted: Tue Aug 02, 2016 9:24 pm Post subject: Complex TCPIP Flow |
 |
|
Disciple
Joined: 30 May 2011
Posts: 177
|
Hi all;
Suppose we have the following 2 message flows(the numbers between paranthesis denot the connection id)
TCPIPServer message flow which calls the business process located some where using WMB bridge facilities :
| Quote: |
TCPIPServerInput(2)===>TCPIPServerReceive(2)===> ... ===>TCPIPServerOutput(2)
|
TCPIPClient message flow which calls the Server message flow Asynchronously by passing the Connectiondetails of socket (1) to the server message flow and receiving it within the client flow as the header of the message:
| Quote: |
Asynch Client out message flow :
TCPIPServerInput(1)===>TCPIPServerReceive(1)===> TCPIPClientOutput(2) which sends the message including the socket id (1) to the above flow
Asynch Client in message flow :
TCPIPClientInput(2) ===> TCPIPClientReceive(2)===> TCPIPServerOutput(1) which receives the message from the above flow with the socket id (1) included in
|
These flows have to be run in a multithreading environment. Setting the input/output streams in the reserved state has confused me and
what i have set now is as follows :
| Quote: |
ServerInput (1)
input stream : Reserve and release at the end of the flow
output stream : Release output stream and reset ReplyID
ServerReceive(1)
input stream : Leave unchanged
output stream : Leave unchanged
ServerOutput(1)
input stream : Leave unchanged
output stream : Leave unchanged
|
| Quote: |
ClientOutput(2)
input stream : Leave unchanged
output stream : Reserve output stream (for use by future TCPIP nodes)
ClientInput(2)
input stream : Reserve input stream (for use by future TCPIP nodes) then release at end of flow
output stream : Release output stream and reset ReplyID
ClientReceive(2)
input stream : Leave unchanged
output stream : Leave unchanged
|
| Quote: |
ServerInput (2)
input stream : Reserve input stream (for use by future TCPIP nodes) then release at end of flow
output stream : Leave unchanged
ServerReceive(2)
input stream : Leave unchanged
output stream : Leave unchanged
ServerOutput(2)
input stream : Leave unchanged
output stream : Leave unchanged
|
please help me if there is something wrong. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Aug 03, 2016 3:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
"there is something wrong" really depends on "does it work or not"...
Otherwise it might be helpful to draw a simple line and block diagram that shows the interaction between IIB and the business system.
Something that shows more than one instance of the flow, with lines showing the connections each instance has to the business system.
Then make some notes about how long each connection needs to hang around and whether it's okay to reuse the same connection from one instance of the flow to another.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PEPERO |
| Posted: Wed Aug 03, 2016 8:58 pm Post subject: |
|
|
Disciple
Joined: 30 May 2011
Posts: 177
|
No it doesn't work.
The main purpose of the implementation is to support an origin requestor to have a "write to socket" thread , and a "read back the response" thread. Behind which the business requested is processed to receive the request and prepare the response related .The originator aquires a "write only to the socket" thread and only writes to the socket within that thread no matter what is the response. Although the originator aquires a "read the response from socket" thread and correlates the responses with some fields that has been previously written to a database in the write thread.
The process request flow is already operational and is working well (the first message flow) shown above and we are going to improve the total system through put because the message flow is a synchrounised TCPIP message flow but the clients use TCPIP in asynch mode.
When using a single thread , every thing is ok but when multithreads are used every thing stops suddenly. The business processes are located in a high performance system and there is no matter what kind of process is requested.
when there is a single thread and a message goes to TCPIPServerInput(1) node , the whole message is retrived from the socket and the message is routed to the server flow (TCPIPServerInput(2) node) through TCPIPClientOutput(2) node. When the response is prepared , it is sent back using TCPIPServerOutput(2) and is read fully with TCPIPClientInput(2) and TCPIPClientReceive(2). Then it is delivered to the requester (Origin) through TCPIPServerOutput(1). |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 04, 2016 3:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Okay... based on what you've said, this is a wild guess.
The use of reserved streams may be causing the problem. If you reserved the connection with multiple instances, each instance may be trying to use the same stream - which would be kind of bad.
Again, a wild guess.
Worth a try to not reserve streams - in an orderly fashion, to see if you can figure out where the issue comes in.
And, again, for a problem of this nature, I might draw the box and arrow diagram just to make sure I understand the intended dataflow, so I can match the properties of the TCP ndoes to match that.
_________________
chmod -R ugo-wx / |
|
| 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
|
|
|
|
