Not stable connection using multiple gateway?

[Sang tai tat]

Dear All,
We have a problem connection about socket when apply flow:
Client -> Gateway A -> Gateway B -> NCC -> Bank host

Usually get Error "Connection Reset" cause error bellow
 at java.base/java.io.DataInputStream.readFully(DataInputStream.java:202)
 at org.jpos.atom.channel.EXIMChannel.getMessageLength(EXIMChannel.java:253)
in Gateway B, sometime it work well or after restart Gateway B

But if I try to call direct from client ->  NCC (Bank host) it work like a charm
Could you guy help me about this issue?

[Mark S]

On Saturday, March 18, 2023 at 6:53:10 AM UTC taita...@gmail.com wrote:

We have a problem connection about socket when apply flow:
Client -> Gateway A -> Gateway B -> NCC -> Bank host

Usually get Error "Connection Reset" cause error bellow
 at java.base/java.io.DataInputStream.readFully(DataInputStream.java:202)
 at org.jpos.atom.channel.EXIMChannel.getMessageLength(EXIMChannel.java:253)
in Gateway B, sometime it work well or after restart Gateway B

I figure that your blocking read from the network to get the length is timing out as the gateway is not sending anything (because it was nothing to send?) 

you would just retry or implement a heartbeat to keep the channel active and avoid the timeout.

We don;t have your code, so it is for you to examine really.

But if I try to call direct from client ->  NCC (Bank host) it work like a charm

Then it is obviously the gateway interface process flow implementation that causes your code times out and needs to handle.

 

Could you guy help me about this issue?

Hopefully.

I did reject your 'chaser' posting, there is no value or need in 'chasing' a response in an open/free group. 

-- 

Mark

[Sang tai tat]

yup, thank a lot for the answer, I will try to testing both solution.

Vào lúc 15:53:09 UTC+7 ngày Thứ Hai, 20 tháng 3, 2023, Mark S đã viết:

[murtuza chhil]

If your calculation of length interprets the message length e.g. 40 but you the actual messgelength is say 38, the channel will wait for 2 bytes that it never receives or receives the next message from which it extracts 2 bytes leaving the next message short of bytes and so on. 

-chhil

[Mark Salter]

Hi Chill, I read the partial stack trace like the EXIMChannel.getMessageLength read of the bytes to get the length that was timing out and am presuming the length is first; but the source will confirm that if shared.

-- 

Mark

Sent from Proton Mail mobile



-------- Original Message --------

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/3b7d2128-e9d5-4660-b954-1cecee705ba7n%40googlegroups.com.