tcp_acknak.pdl

  • Creator
    Topic
  • #49536
    Chak Kwok Yin
    Participant

    In Clovertech forum, I’ve found some communications regarding of internal connections. One thing brought up is that tcp_acknak.pdl instead of the typical mlp_tcp.pdl should be used.

    Can I know the difference between the two and can I’ve a copy of this tcp_acknak.pdl? Would this help in the problem described below?

    We’re having problem where the receiver didn’t respond with ACK and resulting pending messages in the sender. Receiver just return “ACK” for each message received.

    After a 10 to 12 mins, sender starts ACK again and pending messages were all cleared but this cause long latency.

    Below is how we configure this sender and receiver;

    In site A: Inbound Thread -> Send Thread.  Send thread is defined as a PDL TCP-IP client to local host and local port;

    In site B: Receive Thread -> Outbound Thread. The Receive thread is defined as a PDL TCP-IP server with the port defined in the Send Thread. The pdl for the send/receive threads is mlp_tcp.pdl.

Viewing 7 reply threads
  • Author
    Replies
    • #62364
      Richard Hart
      Participant

      Chak.

      Our setup involves many Cloverleaf site to Cloverleaf site communications and it is here that we use the tcp_acknak PDL code.

      In short, the mlp_tcp PDL code creates a delivery envelope for the message and delivery is successful when a TCP level ACK is received.

      The tcp_acknak creates a delivery envelope for the message and delivery is successful when an application level ACK is received.

      If, using just the mlp_tcp PDL, a Cloverleaf receiving thread is shutdown after the TCP level ACK has been sent, the message can be lost.

      I’m not sure who provided this code a few years ago – we have changed it a tad, adding the RCS is in our log file format

      You’ll need to rename the file ‘.pdl’ and put it into an appropriate ‘pdls’ directory and compile it with ‘hcipdc’.

    • #62365
      Chak Kwok Yin
      Participant

      Hi Richard Hart

      Really appreciate your help. We’ve tested it on our testing environment for those internal connections and the ACK for each received message is pretty good; 98.92% of 5,000 messages falls within 1 sec latency.

      However, we did encounter this issue where sender could not sent:

      [pdl :PDL :ERR /0:     AOB_ADTP] Length encoding wrong?: read len of 100663296

      09/27/2007 15:26:19

      [pdl :PDL :ERR /0:     AOB_ADTP] DFA_BLOCK/internal:: could not decode length field (2.0)

      09/27/2007 15:26:19

      [pdl :PDL :ERR /0:     AOB_ADTP] no-match: no more phrases to try

      (RESEND_OB_MSG/AOB_ADTP) No saved msg to resend.  Resending using new copy…

      We suppect that the sender is sending blank reply so we’ve change the TCL to a better handle this. We’ll continue to monitor on this. By the way, are we on the right track to suspect this?

      Regards,

      Chak

    • #62366
      Richard Hart
      Participant

      Chak.

      The output looks like you are using the ‘resend’ code and the tcp_acknak.  If you are using the resend code, the tcp_acknak code will slow you down!

      I can’t explain this, but this error is normally caused when a message has an unexpected delivery envelope.

      If you put the debug on (enable_all), you should see raw message being read and this may provide enough detail …

      read 60 bytes

      input buffer accepted 60 bytes, now 60

      00 00 00 38  4d 53 48 7c  |…8MSH||

      ….

    • #62367
      Chak Kwok Yin
      Participant

      Hi Richard Hart

      Yes, we’re using resend after 60 secs timeout at sender thread. Ok, will removed the resend tcl and test it out too.

      Currently, we’re also find that one of the connection to database in the same process of the receiver thread would’ve cause this slowness due to database performance.

    • #62368
      Richard Hart
      Participant

      Chak.

      I ran our ‘resend’ test procedure using the tcp_acknak PDL and found the odd  issue (no message were lost) with the tcp ACK not being received in time.

      I had no issue with the normal MLLP envolope.

    • #62369
      Chak Kwok Yin
      Participant

      Hi Richard Hart

      Finally, our database administrator have the database fine tuned and the slowness is resolved. The tables are growing huge and monthly maintenance needs to be in place besides regular archiving.

      We’ve returned back to mlp_tcp.pdl because the ACK didn’t return in time and causing pending messages with tcp_acknak.pdl.

      Also, I find that thread using tcl to insert messages to database, can be rather unstable. Sometime, thread can be not responsive to shut down or start up command and some how later it’s back to normal again.

      Appreciate for all your help.

      Regards

      Chak

    • #62370
      Jim Rawls
      Participant

      In this pdl there is a timeout value which is set to 600000.  What does that represent in seconds (or minutes)?

      Thanks,

      Jim

    • #62371
      Chris Williams
      Participant

      Usually it is in milliseconds.

Viewing 7 reply threads
  • The forum ‘Cloverleaf’ is closed to new topics and replies.

Forum Statistics

Registered Users
5,125
Forums
28
Topics
9,294
Replies
34,439
Topic Tags
287
Empty Topic Tags
10