2

I am connecting to a host using the config below, which has the timeout property too. Now my question is why do I again need to pass the timeout param to QMUX.request(msg, timeout) ? my understanding is that, the purpose of <property name="timeout" value="60000"/> and timeout param of QMUX.request(msg,timeout) method same. please correct me if I am wrong.

 <channel-adaptor name="my-channel-adaptor"
                     class="org.jpos.q2.iso.ChannelAdaptor"
                     logger="Q2"
                     realm="my-channel-realm"
                     pool-size="50"
                     thread-pool-size="10">
      <channel class="org.jpos.iso.channel.ASCIIChannel"
               packager="org.jpos.iso.packager.GenericPackager">
        <property name="host" value="localhost"/>
        <property name="port" value="65000"/>
        <property name="timeout" value="60000"/>
        <property name="maxPacketLength" value="4096"/>
        <property name="header" value="600"/>
        <property name="lengthHeader" value="2"/>
        <property name="keepAlive" value="true"/>
      </channel>
    </channel-adaptor>
Sanjok
  • 341
  • 1
  • 9

2 Answers2

1

My understanding is that, the purpose of <property name="timeout" value="60000"/> and timeout param of QMUX.request(msg,timeout) method same.

I don't think so.

  • The former results in setSOTimeout being called on each Socket as it is connected. According to the javadoc, setting an SO_Timeout has the following effect:

    Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout.

    In other words, this is a transport level timeout. I haven't researched what happens when SocketTimeoutException is raised, but I imagine that the channel will be marked as failed ... in some way.

  • The latter is a timeout for the specific request. It is an application protocol timeout. When it occurs, it looks like the request(...) call returns null. The channel will still be alive.

    If you pass zero as the timeout, there is no request level timeout. The request call will wait indefinitely for the response.


Why is QMUX.request() method designed to pass the timeout parameter compulsorily?

That is something you would need to ask the org.jpos designers.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • so, the timeout specified in the channel level is never overridden by the timeout set in QMUX.request() method? – Sanjok Feb 26 '23 at 12:23
  • No. It isn't. They are two separate mechanisms. – Stephen C Feb 26 '23 at 14:10
  • Note: this is based on my reading of the source code, but I only spent a few minutes on it. Feel free to take a longer look at it for yourself. – Stephen C Feb 26 '23 at 14:17
  • When you send a request throught the MUX, you usually wait for a short period of time (i.e. 15 seconds). That's different than the inactivity timeout you can set at the channel level (which defaults to 5 minutes). There's no default timeout at the MUX level, and in almost 25 years that we have the MUX, this question was never raised, but it's actually a good addition we can very easily add. – apr Feb 28 '23 at 01:52
  • Yea. Should be easy to add an overload that maps to `QMUX.request(msg,0)` – Stephen C Feb 28 '23 at 03:27
1

The timeout of the request method is the time it waits for a response.

The timeout of the channel is the time after which it disconnects without any activity.

They are two different things, that's why you need to specify one on the request method.

If you don't want to wait for a response, you can use the send method. If you want to wait forever, you can use a timeout of zero, but this is not recommended.

One more thing, the mux doesn't have a reference to the channel, it talks to it through its queues, so it cannot override any configuration in any way.

Andrés Alcarraz
  • 1,570
  • 1
  • 12
  • 21