Zero Probe Message

[csr]

Hi Team,

Whenever we are receiving zero probe message from the server, our Q2 connection disconnects and attempts to reconnect. Is there any way to handle the zero probe msg without reconnecting.

Regards

CSR

[Mark Salter]

The Channel you are using just needs to be changed to handle the zero or absent length - that you are seeing.

Which Channel class is in play?  What logged messages it is producing in this disconnection scenario?

-- 

Mark

--
--
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/6894aba2-a6a7-486c-a438-913d9fc49e80n%40googlegroups.com.

[Andrés Alcarraz]

BaseChannel has the `expect-keep-alive` property, if your channel extends it, and it doesn't do anything strange, you just need to add the property to the channel.

<property name="expect-keep-alive" value="true"/>

Just keep in mind that it is within the channel element, not the outer `channel-adaptor` or any other xml element you may have in the same file.

Andrés Alcarraz

[csr]

Hi Salter,

We are using PostChannel, there are the channel configuration 

<?xml version="1.0" encoding="UTF-8"?>
<channel-adaptor name='me-channel-1'
                 class="org.jpos.q2.iso.ChannelAdaptor" logger="CacisLogger" start="false">
 
    <channel class="org.jpos.iso.channel.PostChannel" logger="CacisLogger" realm="me-channel-1"
                 packager="org.jpos.iso.packager.GenericPackager">      
        <property name="packager-config" value="/opt/cengine/parser/me_base1.xml" />
        <property name="host" value="10.28.146.55" />
        <property name="port" value="8004" />
        <property name="connection-timeout" value="5000" />
        <property name="timeout" value="36000" />
        <property name="keep-alive" value="true" />  
 
    </channel>

<!--    <ignore-iso-exceptions>yes</ignore-iso-exceptions>-->
    <in>me1-send</in>
    <out>me1-receive</out>
    <reconnect-delay>30000</reconnect-delay>
</channel-adaptor>

We see these messages whenever Zero probe messages receive

<log realm="me-channel-1/10.28.146.55:8004" at="2025-11-17T13:48:17.108" lifespan="30001ms">
  <receive>
    <iso-exception>
      receive length 0 seems strange - maxPacketLength = 100000
      org.jpos.iso.ISOException: receive length 0 seems strange - maxPacketLength = 100000
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:741)
at org.jpos.q2.iso.ChannelAdaptor$Receiver.run(ChannelAdaptor.java:333)
at java.lang.Thread.run(Thread.java:750)
    </iso-exception>
  </receive>
</log>
<log realm="org.jpos.q2.iso.ChannelAdaptor" at="2025-11-17T13:48:17.109">
  <warn>
    channel-receiver-me1-receive
    <iso-exception>
      receive length 0 seems strange - maxPacketLength = 100000
      org.jpos.iso.ISOException: receive length 0 seems strange - maxPacketLength = 100000
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:741)
at org.jpos.q2.iso.ChannelAdaptor$Receiver.run(ChannelAdaptor.java:333)
at java.lang.Thread.run(Thread.java:750)
    </iso-exception>
  </warn>
</log>
<log realm="me-channel-1/10.28.146.55:8004" at="2025-11-17T13:48:19.112" lifespan="1ms">
  <connect>
    Try 0 10.28.146.55:8004
  </connect>
</log>

[Andrés Alcarraz]

Have you tried adding the property I shared? 

----
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/052f1132-860d-4d7e-8edc-45ae8fcbb959n%40googlegroups.com.

[Mark Salter]

@CSR

Did you use  '<property name="expect-keep-alive" value="true"/>' as Andrés suggested?

Please do share your result so that other's may benefit.

-- 

Mark

On 18/11/2025 14:31, csr wrote: