JPOS Reconnection Clarification
vinod kumar
Alejandro Revilla
Read this please: https://jpos.org/blog/2014/04/you-want-a-timeout
Hi Team,I have my own custom channel that extends BaseChannel with properties, timeout = 0 but i am using timeout while sending the request request(m, timeout); , now the problem is it is not connecting back when the connection drops to the server, it is just hanging, Will setting the connect-timeout to 5ms resolve the issue, Please help
--
--
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 visit https://groups.google.com/d/msgid/jpos-users/effa9e1b-09ba-4201-83eb-af3cd2f19463n%40googlegroups.com.
vinod kumar
Doesn't this override the timeout configured in channel XML?
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3D%3DhS9zUeGHSaD7bsTWxVFgZZ7DnNF%2BZCvR5KGsX0KvFZg%40mail.gmail.com.
Andrés Alcarraz
The timeout configured in the channel is the time the socket read will fail with a java.net.SocketTimeoutException if there is no traffic.
The request timeout is at the mux level, and it is how much the mux will wait for a response before returning null if it doesn't arrive. That is for a specific response to that request. You can have other messages arriving to the channel that are not a response for that request, so mux.request can return null, even if there is incoming traffic over the channel.
Hope this clarifies things.
Andrés Alcarraz
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAGAYudJht697oWDNoR8SWq4AJ8jceTxNsLVAoGDUVyhEreCD9A%40mail.gmail.com.
vinod kumar
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/9c6890aa-43c8-43ac-93b7-dd3bb0b24f23%40gmail.com.
Andrés Alcarraz
As apr pointed out, connect-timeout is the time you give a connection to get established.
I meant the timeout at channel level, which is the timeout property of the channel that you said you have set to 0.
Enviado desde mi móvil, disculpas por la brevedad.
Sent from my cellphone, I apologize for the brevity.
Andrés Alcarraz.
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAGAYudJyMpRPO5QjjFDGqpXBb5stbbEA5%2BV5YuWMtZ-oO-0q6A%40mail.gmail.com.
Andrés Alcarraz
Sorry I mixed threads, apr pointed out that in another one.
Enviado desde mi móvil, disculpas por la brevedad.
Sent from my cellphone, I apologize for the brevity.
Andrés Alcarraz.
vinod kumar
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAACHDe2%3DxdTLR85QpGOY5i09CCmcSys3_cVMnQU6mJcJOrwf4A%40mail.gmail.com.
Andrés Alcarraz
The timeout at channel level controls the time a read operation blocks before it fails without receiving data, that is a property of the channel, that is not overridden by the mux timeout parameter to the mux.request.
The mux.requesst timeout only controls the time the mux will wait for a response to that particular message, it has nothing to do with the socket read operation at channel level.
If you have 0 for channel's timeout, and call mux.receive with a different timeout, the mux will return null, but the channel read's operation will still be waiting forever if nothing comes in. Because that channel doesn't know a thing about the mux.request' timeout parameter. If it doesn't know the other party was disconnected it will wait forever, and that's what it hangs and why Apr suggested the "you want a timeout" article.
Why the request.mux timeout and the channels timeout are decoupled is because of what I said in a previous message, there could be a response arriving for another message, or incoming messages from the other side such as echo messages, the mux.request would return null in that case, but the channel is receiving data, and therefore, as it doesn't know a thing about the mux waiting for a response to a particular message it won't give any exception. That situation is indistinguishable from the one in which there was no incoming message from the channel's perspective if the channel's timeout is 0.
That's why we are telling you to set a timeout greater than 0 to the channel, and we are not talking about the connect timeout.
Enviado desde mi móvil, disculpas por la brevedad.
Sent from my cellphone, I apologize for the brevity.
Andrés Alcarraz.
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAGAYudJemsO0YSAnp9jEaPO0nTkHN7rhTOsXbZ9dv6_%2B%3DzBCBA%40mail.gmail.com.
chhil
In jPOS, the MUX and channel communicate via in/out queues (spaces). It’s important to understand that in the deployment configuration, the MUX and channel in/out queues are inverted to enable bidirectional message flow—i.e., sending and receiving of requests and responses through shared spaces.
When you set the MUX timeout to 0, it tells the MUX to wait indefinitely for a response message that the channel is expected to place in the shared space. However, it’s crucial to realize that the MUX has no awareness of the underlying TCP connection—it operates purely at the messaging layer via these queues.
The MUX does have an isConnected() method, but this merely checks for the presence of a "ready" key in the shared space (typically placed there by the channel). If that key is missing, isConnected() returns false. However, when waiting for a response, the MUX does not re-check whether that ready key has disappeared—meaning it will continue waiting forever if the channel has disconnected. Even after reconnecting it is still waiting for the response and that response will never come and its lost.
Also note: once a blocking mux.request() is issued, there is no way to cancel it. If the response never arrives, the thread will remain blocked indefinitely with your timeout of 0.
If you need non-blocking behavior, you can use the asynchronous request() variant, which takes a response handler. This allows you to process the response if and when it arrives without blocking the thread. But be cautious, in your case you continue to do asynch request and those handlers will just pileup creating a resource leak as the responses never arrive.
See related code in the jPOS source for reference:
Bottom Line:
Your issue stems from setting the timeout to 0. This is almost always a bad idea. Your timeout value should align with the service-level expectation for receiving a response—e.g., 5 seconds, 30 seconds, etc. If the response arrives within that time, great. If not, your application should treat it as a no-response scenario and proceed with appropriate fallback logic.
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAACHDe1J9YKaNf1pin81zq%2BLstXhLCpn41LSoC6GBN%3DuSvUVqQ%40mail.gmail.com.
vinod kumar
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAPazefBwmOE1wiMtqxDLcPo7mWmTJyNZFYYs%2BfjBMKdKikF2cw%40mail.gmail.com.
vinod kumar
murtuza chhil
Andrés Alcarraz
In addition to Chhil’s as usual excellent and detailed answer.
I will add something regarding this part, just in case.
One more thing, how does the reconnect happens, Is it when the channel timeout or mux timeout
The channel
doesn’t know a thing about the timeout of the mux.request,
as mentioned before, the mux is decoupled from the channel. They
connect through queues, the channel could be receiving other
messages, or even a response to the request that for some reason
could not be matched by the mux. That would mean that there is
traffic over the socket, and thus, the read won’t time out.
The only thing that happens when there is no response before the mux request’s timeout, is that the mux.request will return null.
I hope this helps to clarify a little more, but please, as Chhil suggested, read the docs. The jPOS programmer’s guide is a must-read, and it should be kept as a reference for everyone working with jPOS regularly, it’s only 152 pages long, so it shouldn’t take long. You don’t have to dominate every concept in the first read, but then you will know where to look for something when you need it. And then, if something is missing or difficutlto understand, you can ask with that ground base.
Andrés Alcarraz
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/8dc106f7-bf20-4f48-8807-7c8362fdb9d1n%40googlegroups.com.
vinod kumar
--
--
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.