Topic
  • 13 replies
  • Latest Post - ‏2013-08-16T14:31:58Z by echurchm
JagadishVemugunta
JagadishVemugunta
37 Posts

Pinned topic DataPower is unable to handle raw TCP outbound connection correctly

‏2013-03-01T18:24:08Z |
I have a requirement to make outbound raw tcp connections to a server. Currently, the application is written in java and is working like champ. However, we have decided to migrate all vendor connections to go through data power.

1) Client code makes http call to an MPG service on DataPower
2) MPG uses a stylesheet to make the backend tcp call.

<xsl:variable name="response">
<dp:url-open response="binaryNode" timeout="20"
target="tcp://host:port">
<xsl:value-of select="." />
</dp:url-open>
</xsl:variable>
Even if the server sends the response within few seconds (1-5 seconds), DataPower will wait for 20 seconds to start reading the response. I did a packet capture and it clearly shows FIN signal is being sent by DataPower only after 20 seconds. In this instance the server is not closing the socket after it sends the response. This to me seems not right. Is there a way to handle this situation better?

In case of my java code

while (data = is.read() != -1)) {}

It is looks like java handles TCP signals perfectly and make life easier for developers.

I want to get the same kind of behavior from DataPower. Please advise
Updated on 2013-04-05T18:21:02Z at 2013-04-05T18:21:02Z by msiebler
  • HermannSW
    HermannSW
    4741 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-03-01T21:56:05Z  
    > Even if the server sends the response within few seconds (1-5 seconds), DataPower will wait for 20 seconds to start reading the response.
    > I did a packet capture and it clearly shows FIN signal is being sent by DataPower only after 20 seconds. In this instance the server is not closing the socket after it sends the response.
    > This to me seems not right.
    >
    Sorry, what do you think is wrong here?
    How should DataPower decide that the server has completed sending the response?
    That is what FIN is about, server has to send the FIN.

    If your backend server cannot do that, you only can reduce backend timeout.
    > Is there a way to handle this situation better?
    >
    > In case of my java code
    >
    > while (data = is.read() != -1)) {}
    >
    > It is looks like java handles TCP signals perfectly and make life easier for developers.
    >
    > I want to get the same kind of behavior from DataPower. Please advise
    >
    Take a packet capture for your Java and see what is different.
    What you described above seems to indicate that the problem is on the backend side.

     
    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>
  • JagadishVemugunta
    JagadishVemugunta
    37 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-03-02T13:54:36Z  
    • HermannSW
    • ‏2013-03-01T21:56:05Z
    > Even if the server sends the response within few seconds (1-5 seconds), DataPower will wait for 20 seconds to start reading the response.
    > I did a packet capture and it clearly shows FIN signal is being sent by DataPower only after 20 seconds. In this instance the server is not closing the socket after it sends the response.
    > This to me seems not right.
    >
    Sorry, what do you think is wrong here?
    How should DataPower decide that the server has completed sending the response?
    That is what FIN is about, server has to send the FIN.

    If your backend server cannot do that, you only can reduce backend timeout.
    > Is there a way to handle this situation better?
    >
    > In case of my java code
    >
    > while (data = is.read() != -1)) {}
    >
    > It is looks like java handles TCP signals perfectly and make life easier for developers.
    >
    > I want to get the same kind of behavior from DataPower. Please advise
    >
    Take a packet capture for your Java and see what is different.
    What you described above seems to indicate that the problem is on the backend side.

     
    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>
    Herman, Here the server side socket implemenations wants of tcp keep-alive (signal) and doesn't wants to close the socket for every client request. Hence the server is not sending the FIN signal after it did TCP PUSH signal.

    In case of the JDK/JRE implementation of sockets, It was written in such a way that once server does send the PUSH signal, the data is availiable in the input stream/reader and a java program can easily ready each byte by byte to determine if the stream is complete using this one line of code.

    while (data = is.read() != -1)) {} . Once the last byte is read, the next byte will be -1 and the java program know the response stream is complete and can act accordingly.

    However, data power implemantation of tcp sockets doesn't know the stream is complete. In other other words <dp:urlopen> does not terminate once the FIN is complete from server. It waits for the read-timeout to happen for response to be read.

    Java's packet capture
    1) Three way hand shake is complete (to establish connection)
    2) Client send PUSH signal with client data
    3) Server ACks PUSH signal for client
    4) Server sends PUSH signal
    5) Client Acks PUSH signal for server.
    6) At this time the response data is availabe in the input stream and the java program reads byte after byte and if the byte is -1 , it knows the complete response has come from the server (steps 1-6 happens within 3 seconds)
    7) java program now sends FIN signal to the server
    8) Three way hand shake is complete (to terminate connection)

    DataPower's packet capture
    1) Three way hand shake is complete (to establish connection)
    2) Client send PUSH signal with client data
    3) Server ACks PUSH signal for client
    4) Server sends PUSH signal
    5) Client Acks PUSH signal for server. (steps 1-5 happens with 3 seconds) ( Here Datapower has the opportunity to read the response stream, but waits for read-timeout)
    6) At this time the <url-open> is still blocked for 20 seconds. After 20 seconds read timeout happens and data power xslt code gets an opportunity to read the response after 23 seconds 20 (read-timeout) + 3 seconds (actual response from the server
    7) java program now sends FIN signal to the server
    8) Three way hand shake is complete (to terminate connection)

    The step at # 5 and 6 in DataPower implementation seems to be not right.

    Additionally, we don't have control how servers implement socket connections and we expect to handle it on the client side. I have sent you the packet captures of both DataPower and Java to your personal email. My example on the packet capture shows as 75 seconds instead of 20 seconds.

    Please review it and let me know what you think.

    Thanks,
    Jagadish
  • JagadishVemugunta
    JagadishVemugunta
    37 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-03-02T16:15:49Z  
    Herman, Here the server side socket implemenations wants of tcp keep-alive (signal) and doesn't wants to close the socket for every client request. Hence the server is not sending the FIN signal after it did TCP PUSH signal.

    In case of the JDK/JRE implementation of sockets, It was written in such a way that once server does send the PUSH signal, the data is availiable in the input stream/reader and a java program can easily ready each byte by byte to determine if the stream is complete using this one line of code.

    while (data = is.read() != -1)) {} . Once the last byte is read, the next byte will be -1 and the java program know the response stream is complete and can act accordingly.

    However, data power implemantation of tcp sockets doesn't know the stream is complete. In other other words <dp:urlopen> does not terminate once the FIN is complete from server. It waits for the read-timeout to happen for response to be read.

    Java's packet capture
    1) Three way hand shake is complete (to establish connection)
    2) Client send PUSH signal with client data
    3) Server ACks PUSH signal for client
    4) Server sends PUSH signal
    5) Client Acks PUSH signal for server.
    6) At this time the response data is availabe in the input stream and the java program reads byte after byte and if the byte is -1 , it knows the complete response has come from the server (steps 1-6 happens within 3 seconds)
    7) java program now sends FIN signal to the server
    8) Three way hand shake is complete (to terminate connection)

    DataPower's packet capture
    1) Three way hand shake is complete (to establish connection)
    2) Client send PUSH signal with client data
    3) Server ACks PUSH signal for client
    4) Server sends PUSH signal
    5) Client Acks PUSH signal for server. (steps 1-5 happens with 3 seconds) ( Here Datapower has the opportunity to read the response stream, but waits for read-timeout)
    6) At this time the <url-open> is still blocked for 20 seconds. After 20 seconds read timeout happens and data power xslt code gets an opportunity to read the response after 23 seconds 20 (read-timeout) + 3 seconds (actual response from the server
    7) java program now sends FIN signal to the server
    8) Three way hand shake is complete (to terminate connection)

    The step at # 5 and 6 in DataPower implementation seems to be not right.

    Additionally, we don't have control how servers implement socket connections and we expect to handle it on the client side. I have sent you the packet captures of both DataPower and Java to your personal email. My example on the packet capture shows as 75 seconds instead of 20 seconds.

    Please review it and let me know what you think.

    Thanks,
    Jagadish
    Sorry, I mean to say in my response as <PUSH> , not FIN

    and the below is the corrected statement

    However, data power implemantation of tcp sockets doesn't know the stream is complete. In other other words <dp:urlopen> does not terminate once the PUSH is complete from server. It waits for the read-timeout to happen for response to be read.
  • HermannSW
    HermannSW
    4741 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-03-02T17:34:21Z  
    Sorry, I mean to say in my response as <PUSH> , not FIN

    and the below is the corrected statement

    However, data power implemantation of tcp sockets doesn't know the stream is complete. In other other words <dp:urlopen> does not terminate once the PUSH is complete from server. It waits for the read-timeout to happen for response to be read.
    Hi Jagadish,

    DataPower implements the TCP spec.
    I am more familiar with the HTTP spec, and the TCP spec is really old (back from 1981):
    Here is the section on closing a (TCP) connection:
    https://tools.ietf.org/html/rfc793#section-3.5

    I cannot see any mentioning in the spec on the procedure you see in Java and want to have in DataPower.
    I cannot see a "PUSH".

    "
    There are essentially three cases:

    1) The user initiates by telling the TCP to CLOSE the connection

    2) The remote TCP initiates by sending a FIN control signal

    3) Both users CLOSE simultaneously
    "

    All three mentioned possibilities to close a connection do involve FINs.

    As you have already identified the implementation of DataPower <dp:url-open> for TCP protocol does wait for a FIN.
    In my eyes the implementation is compliant to RFC793.

     
    So you may create a PMR, but most likely you will get WAD (Works As Designed) as response.
    In that case you still can raise an ER (Enhancement Request).

     
    The only solution I currently see for you now is to reduce the backside timeout to 4 or 5 seconds (becasue steps 1-5 take 3 seconds).
    This will allow processing in less than the 20 seconds.

     
    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>
  • JagadishVemugunta
    JagadishVemugunta
    37 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-03-02T23:12:44Z  
    • HermannSW
    • ‏2013-03-02T17:34:21Z
    Hi Jagadish,

    DataPower implements the TCP spec.
    I am more familiar with the HTTP spec, and the TCP spec is really old (back from 1981):
    Here is the section on closing a (TCP) connection:
    https://tools.ietf.org/html/rfc793#section-3.5

    I cannot see any mentioning in the spec on the procedure you see in Java and want to have in DataPower.
    I cannot see a "PUSH".

    "
    There are essentially three cases:

    1) The user initiates by telling the TCP to CLOSE the connection

    2) The remote TCP initiates by sending a FIN control signal

    3) Both users CLOSE simultaneously
    "

    All three mentioned possibilities to close a connection do involve FINs.

    As you have already identified the implementation of DataPower <dp:url-open> for TCP protocol does wait for a FIN.
    In my eyes the implementation is compliant to RFC793.

     
    So you may create a PMR, but most likely you will get WAD (Works As Designed) as response.
    In that case you still can raise an ER (Enhancement Request).

     
    The only solution I currently see for you now is to reduce the backside timeout to 4 or 5 seconds (becasue steps 1-5 take 3 seconds).
    This will allow processing in less than the 20 seconds.

     
    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>
    Hi Herman,

    I am afraid this option won't work for us. Our application is an real-time application where every second counts for our customers. The current java application is configured for the socket read timeout as 75 seconds. The timeout was kept at this higher number to accomidate bad days for our vendors (service sockets), the vendor systems can take more processing time on the server side. If I have to wait for read timeout for my tcp responses from data power, I am adding latency overhead on my system even if I get response from the server in 1-2 seconds on a good day. Even though TCP spec doesn't tell who sends the FIN first and is left for implementors, the java implementation of TCP is correct. Otherwise , we would not have seen many socket programs running all these years. No one would have used java for tcp sockets.

    When TCP client on Datapower sends an ACK to a previous PUSH from the server, it had an opporturnity to come out of <dp:open-url> step, but it didn't which to me is a serious drawback in the product. According to the DataPower implementation, if the server is not sending the FIN signal (all modern servers don't do and wants to use tcp keep-alive) , DataPower don't know when the sever response is complete. This limits our usage of DataPower for socket based client implementations.

    Atleast I now know how tcp sockets work within DataPower and foresee the damage it would have put on our systems. I have no option at this point other than stopping TCP socket implementations in DataPower.

    If we put an enhancement request, what would be the ETA to implement this feature in DataPower.

    Thanks for your explanation and your valuable time.

    Regards, Jagadish
  • HermannSW
    HermannSW
    4741 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-03-03T16:14:59Z  
    Hi Herman,

    I am afraid this option won't work for us. Our application is an real-time application where every second counts for our customers. The current java application is configured for the socket read timeout as 75 seconds. The timeout was kept at this higher number to accomidate bad days for our vendors (service sockets), the vendor systems can take more processing time on the server side. If I have to wait for read timeout for my tcp responses from data power, I am adding latency overhead on my system even if I get response from the server in 1-2 seconds on a good day. Even though TCP spec doesn't tell who sends the FIN first and is left for implementors, the java implementation of TCP is correct. Otherwise , we would not have seen many socket programs running all these years. No one would have used java for tcp sockets.

    When TCP client on Datapower sends an ACK to a previous PUSH from the server, it had an opporturnity to come out of <dp:open-url> step, but it didn't which to me is a serious drawback in the product. According to the DataPower implementation, if the server is not sending the FIN signal (all modern servers don't do and wants to use tcp keep-alive) , DataPower don't know when the sever response is complete. This limits our usage of DataPower for socket based client implementations.

    Atleast I now know how tcp sockets work within DataPower and foresee the damage it would have put on our systems. I have no option at this point other than stopping TCP socket implementations in DataPower.

    If we put an enhancement request, what would be the ETA to implement this feature in DataPower.

    Thanks for your explanation and your valuable time.

    Regards, Jagadish
    Hi Jagadish,
    >
    > ...
    > When TCP client on Datapower sends an ACK to a previous PUSH from the server, it had an opporturnity to come out of <dp:open-url> step, but it didn't
    >
    sorry, I do not see how dp:url-open has an opportunity to "come out".
    If DataPower would continue with the first packet received, and without having sent a FIN itself or received a FIN from backend, that would be plain wrong (at least for dp:url-open).
    The reason is that the only way to "come out" for dp:url-open would be "to do as if FIN has been received".
    But then another packet sent by backend cannot be recieved anymore.
    This does not happen in your application, but how should dp:url-open know?

    > which to me is a serious drawback in the product.
    >
    The drawback is that dp:url-open is monolithic, and does not provide the flexibility your Java code does.

    > According to the DataPower implementation, if the server is not sending the FIN signal (all modern servers don't do and wants to use tcp keep-alive) , DataPower don't know when the sever response is complete.
    >
    Correct, but that is how it was designed and implemented long ago.
    And according dp:url-open being monolithic being the only correct way and being spec compliant.

    >This limits our usage of DataPower for socket based client implementations.
    >
    Agreed.

    > At least I now know how tcp sockets work within DataPower and foresee the damage it would have put on our systems.
    > I have no option at this point other than stopping TCP socket implementations in DataPower.
    >
    > If we put an enhancement request, what would be the ETA to implement this feature in DataPower.
    >
    I do not know about ETAs for ERs.
    But if you raise an ER, you would need to specify "what" and "how" you want to change.
    As said above, you need to specify "how" you want dp:url-open to behave in your scenario, and especially what to do if server later sends another packet (which is valid since the connection is open).

     
    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>
  • JagadishVemugunta
    JagadishVemugunta
    37 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-03-04T16:34:53Z  
    • HermannSW
    • ‏2013-03-03T16:14:59Z
    Hi Jagadish,
    >
    > ...
    > When TCP client on Datapower sends an ACK to a previous PUSH from the server, it had an opporturnity to come out of <dp:open-url> step, but it didn't
    >
    sorry, I do not see how dp:url-open has an opportunity to "come out".
    If DataPower would continue with the first packet received, and without having sent a FIN itself or received a FIN from backend, that would be plain wrong (at least for dp:url-open).
    The reason is that the only way to "come out" for dp:url-open would be "to do as if FIN has been received".
    But then another packet sent by backend cannot be recieved anymore.
    This does not happen in your application, but how should dp:url-open know?

    > which to me is a serious drawback in the product.
    >
    The drawback is that dp:url-open is monolithic, and does not provide the flexibility your Java code does.

    > According to the DataPower implementation, if the server is not sending the FIN signal (all modern servers don't do and wants to use tcp keep-alive) , DataPower don't know when the sever response is complete.
    >
    Correct, but that is how it was designed and implemented long ago.
    And according dp:url-open being monolithic being the only correct way and being spec compliant.

    >This limits our usage of DataPower for socket based client implementations.
    >
    Agreed.

    > At least I now know how tcp sockets work within DataPower and foresee the damage it would have put on our systems.
    > I have no option at this point other than stopping TCP socket implementations in DataPower.
    >
    > If we put an enhancement request, what would be the ETA to implement this feature in DataPower.
    >
    I do not know about ETAs for ERs.
    But if you raise an ER, you would need to specify "what" and "how" you want to change.
    As said above, you need to specify "how" you want dp:url-open to behave in your scenario, and especially what to do if server later sends another packet (which is valid since the connection is open).

     
    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>
    Herman, If not dp:url-open, Can we make this work with an MPG

    I created a simple MPG, with backend url as tcp://host:port. The response rule is never fired and I always see read-timeout error in the logs as below.

    rule (medicaid_rt_policy_rule_res): implied action Read input as binary data failed: Network error.
    mpgw (medicaid_rt_mpg): A timeout occurred when reading or writing through the default identity processor.
  • msiebler
    msiebler
    140 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-04-05T18:21:02Z  
    Herman, If not dp:url-open, Can we make this work with an MPG

    I created a simple MPG, with backend url as tcp://host:port. The response rule is never fired and I always see read-timeout error in the logs as below.

    rule (medicaid_rt_policy_rule_res): implied action Read input as binary data failed: Network error.
    mpgw (medicaid_rt_mpg): A timeout occurred when reading or writing through the default identity processor.
    Jagadish; for the MPGW using 'tcp' as a backend; if the response data is well-formed xml; then our device will not wait for the FIN or timeout before processing the data.
    Our box will find the end of the document and process the data immediately.

    However this will only work for XML; for arbitrary binary data we will wait as you saw for the timeout or FIN
  • HermannSW
    HermannSW
    4741 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-04-15T20:19:23Z  
    • msiebler
    • ‏2013-04-05T18:21:02Z
    Jagadish; for the MPGW using 'tcp' as a backend; if the response data is well-formed xml; then our device will not wait for the FIN or timeout before processing the data.
    Our box will find the end of the document and process the data immediately.

    However this will only work for XML; for arbitrary binary data we will wait as you saw for the timeout or FIN

    Thanks Matthias, that really works!

    I did start a "netcat" backend simulation on server 9.152.92.85.

    After receiving the "<x/>" request from DataPower (second 8.03), I did hit "return" to go to next line (second 11.23).
    Then I did enter the "<data>" line and return (second 17.11).
    Immediately then the response rule got triggered and the doubled output gets returned by curl.
    Finally I pressed "^C" (CTRL+C) to terminate the (still running) netcat server (second 23.03).
     

    "netcat" server:

    $ nc -l 6789
    <x/>
    <data>123</data>
    ^C
    $


    "curl" client accessing MPGW on dp3-l3 appliance:
    $ curl --data-binary "<x/>" http://dp3-l3:1234 ; echo
    <out><data>123</data><data>123</data></out>
    $

    The MPGW consisted of:

    • HTTP FSH on port 1234
    • passthru request type
    • XML response type
    • match all and xform(double.xsl) actions on response rule
    • "tcp://9.152.92.85:6789" static backend

     

    This is packet capture in Wireshark:


     

    As Matthias already said, this only helps you in case of a XML rawTCP response.


    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>

    Updated on 2013-04-15T20:28:15Z at 2013-04-15T20:28:15Z by HermannSW
  • craig oddy
    craig oddy
    4 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-04-18T09:43:33Z  
    • HermannSW
    • ‏2013-03-02T17:34:21Z
    Hi Jagadish,

    DataPower implements the TCP spec.
    I am more familiar with the HTTP spec, and the TCP spec is really old (back from 1981):
    Here is the section on closing a (TCP) connection:
    https://tools.ietf.org/html/rfc793#section-3.5

    I cannot see any mentioning in the spec on the procedure you see in Java and want to have in DataPower.
    I cannot see a "PUSH".

    "
    There are essentially three cases:

    1) The user initiates by telling the TCP to CLOSE the connection

    2) The remote TCP initiates by sending a FIN control signal

    3) Both users CLOSE simultaneously
    "

    All three mentioned possibilities to close a connection do involve FINs.

    As you have already identified the implementation of DataPower <dp:url-open> for TCP protocol does wait for a FIN.
    In my eyes the implementation is compliant to RFC793.

     
    So you may create a PMR, but most likely you will get WAD (Works As Designed) as response.
    In that case you still can raise an ER (Enhancement Request).

     
    The only solution I currently see for you now is to reduce the backside timeout to 4 or 5 seconds (becasue steps 1-5 take 3 seconds).
    This will allow processing in less than the 20 seconds.

     
    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>

    RFC793 section 2.8 says "When a receiving TCP sees the PUSH flag, it must not wait for more data from the sending TCP before passing the data to the receiving process."    I guess the notion of compliancy depends on what is considered the receiving process, and probably can be interpreted as the OSI layer 7 part of the code, so in this case this would be the code issuing the TCP API and so the url-open implementation itself.   Read as such, url-open is the application here and in terms of RFC can, i guess, do whatever it wants with the PUSH.   For a persistent socket type connection it is a no win either way -- waiting for the FIN is no good because the FIN is never coming so the timeout has to pop; on other hand as Hermann points out above, if url-open were to handle a PUSH by returning control to caller, then there would be cases, with longer messages for example, when control would be returned before all the data was sent, and then no way to get the remaining. 

    We went through a similar experience to Jagadish and ended up accepting that you cannot properly deal with a persistent socket with the current implementation of url-open for raw tcp.  We ended up having to change the server so that it closed the socket at the end of what it was sending for that "transaction" (logical exchange).   Obviously, in addition to needing to change the server, there are latency implications going this route. 

    The only kind of thing i can think of in order to deal with persistent sockets would be for IBM to introduce some socket "handle" concept to the url-open api, such that control (and whatever data had been so far received) could optionally be returned to the calling stylesheet when a PUSH was received, but as well some kind of "handle" value would be returned such that a url-open could be called again to continue receiving from that same socket.   This would allow persistent sockets to be used but introduces the additional complexities related to socket pooling and pool management (reaping inactive sockets, etc). 

     

    Updated on 2013-04-18T09:46:28Z at 2013-04-18T09:46:28Z by craig oddy
  • Kreg
    Kreg
    16 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-06-28T18:44:35Z  
    • HermannSW
    • ‏2013-03-01T21:56:05Z
    > Even if the server sends the response within few seconds (1-5 seconds), DataPower will wait for 20 seconds to start reading the response.
    > I did a packet capture and it clearly shows FIN signal is being sent by DataPower only after 20 seconds. In this instance the server is not closing the socket after it sends the response.
    > This to me seems not right.
    >
    Sorry, what do you think is wrong here?
    How should DataPower decide that the server has completed sending the response?
    That is what FIN is about, server has to send the FIN.

    If your backend server cannot do that, you only can reduce backend timeout.
    > Is there a way to handle this situation better?
    >
    > In case of my java code
    >
    > while (data = is.read() != -1)) {}
    >
    > It is looks like java handles TCP signals perfectly and make life easier for developers.
    >
    > I want to get the same kind of behavior from DataPower. Please advise
    >
    Take a packet capture for your Java and see what is different.
    What you described above seems to indicate that the problem is on the backend side.

     
    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>

    We are having essentially the same problem. We have a high-throughput application in which we want to use DataPower to send large numbers of events to IBM WebSphere Streams. We cannot use TCP because the connections never close. Each instance of url-open opens a new connection, but each connection stays open until it times out. This immediately fills the DataPower memory as connections stack up in memory, waiting for thier timeout to occur.

    At a rate of up to a couple of hundred transactions per second, we soon lose all control of the appliance and have to wait for it to crash an reset. Useless. DataPower give me no control over the tcp connection and my Streams guy says he has none. Why even have it as an option, then?

    One would think the using two WebSphere products to do something so simple would be more straightforward. I suppose though, that I'm approaching it all wrong. I should be asking, given these two products (DP XI50 and Streams) what is the best integration approach for this sort of volume?

     

  • HermannSW
    HermannSW
    4741 Posts

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-06-29T10:08:46Z  
    • Kreg
    • ‏2013-06-28T18:44:35Z

    We are having essentially the same problem. We have a high-throughput application in which we want to use DataPower to send large numbers of events to IBM WebSphere Streams. We cannot use TCP because the connections never close. Each instance of url-open opens a new connection, but each connection stays open until it times out. This immediately fills the DataPower memory as connections stack up in memory, waiting for thier timeout to occur.

    At a rate of up to a couple of hundred transactions per second, we soon lose all control of the appliance and have to wait for it to crash an reset. Useless. DataPower give me no control over the tcp connection and my Streams guy says he has none. Why even have it as an option, then?

    One would think the using two WebSphere products to do something so simple would be more straightforward. I suppose though, that I'm approaching it all wrong. I should be asking, given these two products (DP XI50 and Streams) what is the best integration approach for this sort of volume?

     

    By the reasons I described above and agreed upon by Craig, DataPower cannot know for binary data responses when the response is complete without getting a FIN. This cannot be changed because otherwise above mentioned problems occur..

    As shown in my previous response, DataPower does not always have to wait for a FIN.
    In case of a XML response DataPower knows when the XML reponse is complete and processes reponse XML data before FIN is received.


    Now looking into documentation for Infosphere Streams "-F tcp" seems to be the option you wanted to use:
    http://pic.dhe.ibm.com/infocenter/streams/v3r1/index.jsp?topic=%2Fcom.ibm.swg.im.infosphere.streams.cfg.doc%2Fdoc%2Ftranspoptions.html

    I have no experience with that product, but it seems that this product is intended to just receive huge amount of events.
    Therefore there seems to be no response sent back or even a need for that.

    Also it does not make sense for this product to close connections because that would reduce system throughput.


    > One would think the using two WebSphere products to do something so simple would be more straightforward.
    >
    Given the different design goals of both products (DataPower assumes XML returns or FINs, Infosphere Streams
    does not do that (for good reasons)), it cannot be easy.


    > I should be asking, given these two products (DP XI50 and Streams) what is the best integration approach for this sort of volume?
    >
    You may try to insert a TCP service between DataPower and Infosphere Streams, that just takes DataPowe TCP request,
    sends to Infosphere Streams, and then closes connection to DataPower enabling dp:url-open to complete.

    Otherwise, you may set a small  @timeout  value in <dp:url-open>, with "1" (second) being the minimum.


    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>

  • echurchm
    echurchm
    1 Post

    Re: DataPower is unable to handle raw TCP outbound connection correctly

    ‏2013-08-16T14:31:58Z  

    I am working on a similar scenario but I a receiving raw tcp using a Stateless Raw XML Handler. I have the same issue that DataPower will not send the data through the processing rule unless the client closes the connection or the front side connection times out.  In my case,  I don't necessarily need persistent connections but I need to respond to the client with standard acknowledgment. Since DataPower is never going into the processing rule I cannot process it and respond.  I took a packet trace and I can see that the client is sending a tcp PSH.  Based on this thread, it seems that DataPower does not use the PSH flag to start processing the data it has already received. Is this an accurate statement?

     

     

    I appreciate any feedback.

     

    Thanks Ed.

     

    Updated on 2013-08-16T14:36:19Z at 2013-08-16T14:36:19Z by echurchm