QMUX class unable to receive response from server

Vincent

unread,

Jul 21, 2025, 9:43:32 AMJul 21

to jPOS Users

Hi fellow JPOS experts,

I wanted to ask a very strange case in my place and it happening intermittently, let me explain the context first.

So i am having an ISO Client built with JPOS QServer, and I used org.jpos.q2.iso.QMUX class and QMUX.request() method to send and receive ISOMsg, at some occurrence the method are able to receive the response from the server.
But at some time, it couldn't handle the response that it got from the server. The response was printed on the logger file that attached to the channel-adaptor.xml,

the response supposed to be very fast and doesn't count as a timeout,

but the QMUX.request() doesn't receive any response and take it as timeout.

Below are the log that are received from the file logger

<log realm="channel/192.168.xx.zz:65005" at="Fri Jul 18 03:45:00 WIB 2025.385" lifespan="1ms">
<send>
<isomsg direction="outgoing">

<header>49534F303135303030303130</header>
<field id="0" value="0200"/>
<field id="3" value="401000"/>
<field id="4" value="000000600000"/>
<field id="7" value="0717204500"/>
<field id="11" value="001846"/>
<field id="12" value="034500"/>
<field id="13" value="0718"/>
<field id="17" value="0718"/>
<field id="22" value="021"/>
<field id="32" value="00000000002"/>
<field id="35" value="1946902692132733=2504101"/>
<field id="37" value="001835 "/>
<field id="41" value="00660109 "/>
<field id="43" value="9938-ADFASDF"/>
<field id="48" value="Ibu * "/>
<field id="49" value="360"/>
<field id="52" value="37108116E6DAD949"/>
<field id="60" value="BPRI "/>
<field id="100" value="10000000009"/>
<field id="103" value="0926106915"/>
<field id="110" value="360002"/>
<field id="120" value="9938"/>
<field id="125" value="3"/>
<field id="127" value="10000000009"/>
</isomsg>
</send>
</log>
<log realm="channel/192.168.xx.zz:65005" at="Fri Jul 18 03:45:00 WIB 2025.649">
<got-message-length>
419
</got-message-length>
</log>
<log realm="channel/192.168.xx.zz:65005" at="Fri Jul 18 03:45:00 WIB 2025.650">
<get-message-trailler/>
</log>
<log realm="channel/192.168.xx.zz:65005" at="Fri Jul 18 03:45:00 WIB 2025.650">
<got-message-trailler>
03
</got-message-trailler>
</log>
<log realm="channel/192.168.xx.zz:65005" at="Fri Jul 18 03:45:00 WIB 2025.650" lifespan="23551ms">
<receive>
<isomsg direction="incoming">

<header>49534F303135303030303131</header>
<field id="0" value="0210"/>
<field id="3" value="401000"/>
<field id="4" value="000000600000"/>
<field id="7" value="0717204500"/>
<field id="11" value="001846"/>
<field id="12" value="034500"/>
<field id="13" value="0718"/>
<field id="15" value="0718"/>
<field id="17" value="0718"/>
<field id="22" value="021"/>
<field id="32" value="00000000002"/>
<field id="35" value="1946902692132733=2504101"/>
<field id="37" value="001835 "/>
<field id="38" value="213736"/>
<field id="39" value="51"/>
<field id="41" value="00660109 "/>
<field id="43" value="9938-ADFASDF"/>
<field id="44" value="2000000000000000000000000"/>
<field id="48" value="IBU FILTER"/>
<field id="49" value="360"/>
<field id="60" value="BPRI "/>
<field id="100" value="9"/>
<field id="102" value="0000000926106915"/>
<field id="103" value="0926106915 "/>
<field id="110" value="360002"/>
<field id="120" value="9938"/>
<field id="125" value="0"/>
<field id="127" value="10000000009"/>
</isomsg>
</receive>
</log>

Do you guys have any idea? Thank you

Andrés Alcarraz

unread,

Jul 21, 2025, 10:05:19 AMJul 21

to jpos-...@googlegroups.com

Most probably, the response isn't matching the key of the request.

That doesn't seem to be the case in your example for the default QMUX configuration, can you share how you are configuring the mux?

Andrés Alcarraz

--
--
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/722fcdf8-cbdd-4052-be87-5c0f98e60f0cn%40googlegroups.com.

Mark Salter

unread,

Jul 21, 2025, 1:08:48 PMJul 21

to jpos-...@googlegroups.com

On 21/07/2025 15:05, Andrés Alcarraz wrote:
> Most probably, the response isn't matching the key of the request.

I would say certainly this, if the default Mux matching criteria is not
overridden :-) !

>
> That doesn't seem to be the case in your example for the default QMUX
> configuration
>

Unless there is something interesting in that odd trailing 'white space'
in field 41!

--

Mark

signature.asc

Vincent

unread,

Jul 22, 2025, 4:18:06 AMJul 22

to jPOS Users

Hi Andres and Mark,

Thanks for your response, let me attached the mux file content for you and try to spot if there is some mistakes in it.

`<?xml version="1.0" encoding="UTF-8"?>
<mux class="org.jpos.q2.iso.QMUX" logger="Q2-B24-BasicBanking-logger" name="b24bnibasicbanking-ecp-qmux">
<key>41 37 11</key>
<in>b24bni-basicbanking-ecp-receive</in>
<out>b24bni-basicbanking-ecp-send</out>
<ready>b24bnibasicbanking-ecp-channel.ready</ready>
<unhandled>b24bnibasicbanking-ecp-qmux.unhandled</unhandled>
<request-listener class="com.iso.client.listener.Base24Listener" logger="Q2-B24-BasicBanking-logger" realm="unhandledrealm">
</request-listener>
</mux>
`

For what i understood the mux, will match field 41,37 and 11 right?
from the ISO Response that I received at the logger, the following fields seems correct and supposed to be read as a response. Also I checked about the whitespaces, it has the same length between the request and the response.

Do you have any other clues?
Thank you.

chhil

unread,

Jul 22, 2025, 4:23:47 AMJul 22

to jpos-...@googlegroups.com

Please share the packager definitions for 11,41 and 37 configured for the channel.

-chhil

--
--
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/c229523e-c718-456e-948e-7bdd991ec9a1n%40googlegroups.com.

Mark Salter

unread,

Jul 22, 2025, 4:25:13 AMJul 22

to jpos-...@googlegroups.com

You are correct on your mum matching statement.

On the 'whitespace' at the end of both those fields, I would fill the whole field with numerical or make the fields shorter on both sides instead of leaving anything 'empty'
Can you also check that the binary data in those trailing/empty positions are actually matching at the byte channel level?

I doubt the mux matching process trims values at all, but would l have a look at the code just in case.

--
Mark

-------- 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 visit https://groups.google.com/d/msgid/jpos-users/c229523e-c718-456e-948e-7bdd991ec9a1n%40googlegroups.com.

signature.asc

murtuza chhil

unread,

Jul 22, 2025, 4:36:53 AMJul 22

to jPOS Users

e.g. field packager for DE41

GenericPackager p = new GenericPackager("path to packager xml");
ISOMsg m = new ISOMsg("0100");
m.setPackager(p);
m.set(41,"1234");
m.dump(System.out, "");
byte[] arr = m.pack();
System.out.println(ISOUtil.hexdump(arr));

Output

<isomsg direction="none">

<field id="0" value="0100"/>
<field id="41" value="1234"/>
</isomsg>
0000 30 31 30 30 30 30 30 30 30 30 30 30 30 30 38 30 0100000000000080
0010 30 30 30 30 31 32 33 34 20 20 20 20 20 20 20 20 00001234
0020 20 20 20 20

Notice the spaces added to 1234 to make it fixed 16 in the hexdump after the pack

When the mux gets the data its "1234" when it hands it over to the channel which sends the data, the channel does a pack on the iso message which makes it 16 wide on the wire.
When the channel receves the response its 16, hands it over to mux as 16 wide. The mux looks for the key but cannot match it.

-chhil

Message has been deleted

Mark Salter

unread,

Jul 22, 2025, 8:01:15 AMJul 22

to jpos-...@googlegroups.com

Potentially Vincent is setting the fields with the spaces (if they are) innplace.

The code setting the values and the Packager hold the confirmation needed.

QMUX.java does have manipulation for field 11, so people might get away with this approach on that field alone.

@Vincent, please confirm the detail you are placing in each field as well as the packager details for the matching fields.

I would still avoid spaces at all possible cost either implicity or explicity.

--
Mark

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

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/16aab0ed-ced8-4439-9ac1-dd873d5b34e9n%40googlegroups.com.

signature.asc

Message has been deleted

Mark Salter

unread,

Jul 22, 2025, 9:50:59 AMJul 22

to jpos-...@googlegroups.com

Just to close this topic off.

Vincent confirmed (offlist as he was having trouble replying on this thread) that he was not setting the spaces, so yopur theory Chhil is confirmed.

Always fully complete/fill your fields people, otherwise the MUX matching will not work correctly as it doesn't consider the shortfall.

Great spot Chhil :-)

--

Mark

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/NaK-v_MsQI5QKKzCQx_NsoO3BslzBSQ0OH0ZfcdhWgVsqYZJuhUwPjYOdbeNoMIuzRQ7mYuPCkkeWRMDwMNj7WO6KsYGiomT0KI3K2mvojI%3D%40pm.me.

signature.asc

Vincent

unread,

Jul 22, 2025, 10:05:53 AMJul 22

to jPOS Users

Hi Murtuza Chhil,

Below i attached the packager that i used for the channel adaptor to send the ISOmsg, you are correct it automatically makes it wide to 16 character, but some of the successful transaction also have a whitespace at fields 41. Strange thing is only some of them is failed.

Also @Mark, so you suggested me to do a tcpdump to check the message from network level?

B24.xml

Vincent

unread,

Jul 22, 2025, 10:06:36 AMJul 22

to jPOS Users

Hi Chhil and Mark,

I wonder why the message got deleted before, i attached my packager related to channel adaptor, is attaching file is prohibited?

To add some context, only few of the transactions are failed, mostly the transaction has whitespaces on fields 41, and it has no problem.

Below i just posted a text content of the packager that i used.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE isopackager SYSTEM "genericpackager.dtd">



<isopackager>
<isofield
id="0"
length="4"
name="MESSAGE TYPE INDICATOR"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="1"
length="16"
name="BIT MAP"
class="org.jpos.iso.IFA_BITMAP"/>
<isofield
id="2"
length="19"
name="PAN - PRIMARY ACCOUNT NUMBER"
class="org.jpos.iso.IFA_LLNUM"/>
<isofield
id="3"
length="6"
name="PROCESSING CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="4"
length="12"
name="AMOUNT, TRANSACTION"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="5"
length="12"
name="AMOUNT, SETTLEMENT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="6"
length="12"
name="AMOUNT, CARDHOLDER BILLING"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="7"
length="10"
name="TRANSMISSION DATE AND TIME"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="8"
length="8"
name="AMOUNT, CARDHOLDER BILLING FEE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="9"
length="8"
name="CONVERSION RATE, SETTLEMENT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="10"
length="8"
name="CONVERSION RATE, CARDHOLDER BILLING"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="11"
length="6"
name="SYSTEM TRACE AUDIT NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="12"
length="6"
name="TIME, LOCAL TRANSACTION"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="13"
length="4"
name="DATE, LOCAL TRANSACTION"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="14"
length="4"
name="DATE, EXPIRATION"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="15"
length="4"
name="DATE, SETTLEMENT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="16"
length="4"
name="DATE, CONVERSION"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="17"
length="4"
name="DATE, CAPTURE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="18"
length="4"
name="MERCHANTS TYPE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="19"
length="3"
name="ACQUIRING INSTITUTION COUNTRY CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="20"
length="3"
name="PAN EXTENDED COUNTRY CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="21"
length="3"
name="FORWARDING INSTITUTION COUNTRY CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="22"
length="3"
name="POINT OF SERVICE ENTRY MODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="23"
length="3"
name="CARD SEQUENCE NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="24"
length="3"
name="NETWORK INTERNATIONAL IDENTIFIEER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="25"
length="2"
name="POINT OF SERVICE CONDITION CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="26"
length="2"
name="POINT OF SERVICE PIN CAPTURE CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="27"
length="1"
name="AUTHORIZATION IDENTIFICATION RESP LEN"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="28"
length="9"
name="AMOUNT, TRANSACTION FEE"
class="org.jpos.iso.IFA_AMOUNT"/>
<isofield
id="29"
length="9"
name="AMOUNT, SETTLEMENT FEE"
class="org.jpos.iso.IFA_AMOUNT"/>
<isofield
id="30"
length="9"
name="AMOUNT, TRANSACTION PROCESSING FEE"
class="org.jpos.iso.IFA_AMOUNT"/>
<isofield
id="31"
length="9"
name="AMOUNT, SETTLEMENT PROCESSING FEE"
class="org.jpos.iso.IFA_AMOUNT"/>
<isofield
id="32"
length="11"
name="ACQUIRING INSTITUTION IDENT CODE"
class="org.jpos.iso.IFA_LLNUM"/>
<isofield
id="33"
length="11"
name="FORWARDING INSTITUTION IDENT CODE"
class="org.jpos.iso.IFA_LLNUM"/>
<isofield
id="34"
length="28"
name="PAN EXTENDED"
class="org.jpos.iso.IFA_LLCHAR"/>
<isofield
id="35"
length="37"
name="TRACK 2 DATA"
class="org.jpos.iso.IFA_LLNUM"/>
<isofield
id="36"
length="104"
name="TRACK 3 DATA"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="37"
length="12"
name="RETRIEVAL REFERENCE NUMBER"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="38"
length="6"
name="AUTHORIZATION IDENTIFICATION RESPONSE"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="39"
length="2"
name="RESPONSE CODE"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="40"
length="3"
name="SERVICE RESTRICTION CODE"
class="org.jpos.iso.IF_CHAR"/>

<isofield
id="41"
length="16"

name="CARD ACCEPTOR TERMINAL IDENTIFICACION"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="42"
length="15"
name="CARD ACCEPTOR IDENTIFICATION CODE"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="43"
length="40"
name="CARD ACCEPTOR NAME - LOCATION"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="44"
length="25"
name="ADITIONAL RESPONSE DATA"
class="org.jpos.iso.IFA_LLCHAR"/>
<isofield
id="45"
length="76"
name="TRACK 1 DATA"
class="org.jpos.iso.IFA_LLCHAR"/>
<isofield
id="46"
length="999"
name="ADITIONAL DATA - ISO"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="47"
length="999"
name="ADITIONAL DATA - NATIONAL"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="48"
length="999"
name="ADITIONAL DATA - PRIVATE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="49"
length="3"
name="CURRENCY CODE, TRANSACTION"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="50"
length="3"
name="CURRENCY CODE, SETTLEMENT"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="51"
length="3"
name="CURRENCY CODE, CARDHOLDER BILLING"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="52"
length="16"
name="PIN DATA"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="53"
length="16"
name="SECURITY RELATED CONTROL INFORMATION"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="54"
length="120"
name="ADDITIONAL AMOUNTS"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="55"
length="999"
name="INTEGRATED CIRCUIT CARD (ICC)"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="56"
length="999"
name="RESERVED ISO"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="57"
length="999"
name="RESERVED NATIONAL"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="58"
length="999"
name="RESERVED NATIONAL"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="59"
length="999"
name="RESERVED NATIONAL"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="60"
length="900"
name="ADVICE REASON CODE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="61"
length="999"
name="RESERVED PRIVATE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="62"
length="999"
name="RESERVED PRIVATE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="63"
length="4"
name="INSTITUTION CODE"
class="org.jpos.iso.IFA_LLNUM"/>
<isofield
id="64"
length="16"
name="MESSAGE AUTHENTICATION CODE FIELD"
class="org.jpos.iso.IFA_BINARY"/>
<isofield
id="65"
length="1"
name="BITMAP, EXTENDED"
class="org.jpos.iso.IFA_BINARY"/>
<isofield
id="66"
length="1"
name="SETTLEMENT CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="67"
length="2"
name="EXTENDED PAYMENT CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="68"
length="3"
name="RECEIVING INSTITUTION COUNTRY CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="69"
length="3"
name="SETTLEMENT INSTITUTION COUNTRY CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="70"
length="3"
name="NETWORK MANAGEMENT INFORMATION CODE"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="71"
length="4"
name="MESSAGE NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="72"
length="4"
name="MESSAGE NUMBER LAST"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="73"
length="6"
name="DATE ACTION"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="74"
length="10"
name="CREDITS NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="75"
length="10"
name="CREDITS REVERSAL NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="76"
length="10"
name="DEBITS NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="77"
length="10"
name="DEBITS REVERSAL NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="78"
length="10"
name="TRANSFER NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="79"
length="10"
name="TRANSFER REVERSAL NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="80"
length="10"
name="INQUIRIES NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="81"
length="10"
name="AUTHORIZATION NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="82"
length="12"
name="CREDITS, PROCESSING FEE AMOUNT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="83"
length="12"
name="CREDITS, TRANSACTION FEE AMOUNT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="84"
length="12"
name="DEBITS, PROCESSING FEE AMOUNT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="85"
length="12"
name="DEBITS, TRANSACTION FEE AMOUNT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="86"
length="16"
name="CREDITS, AMOUNT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="87"
length="16"
name="CREDITS, REVERSAL AMOUNT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="88"
length="16"
name="DEBITS, AMOUNT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="89"
length="16"
name="DEBITS, REVERSAL AMOUNT"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="90"
length="42"
name="ORIGINAL DATA ELEMENTS"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="91"
length="1"
name="FILE UPDATE CODE"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="92"
length="2"
name="FILE SECURITY CODE"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="93"
length="6"
name="RESPONSE INDICATOR"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="94"
length="7"
name="SERVICE INDICATOR"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="95"
length="42"
name="REPLACEMENT AMOUNTS"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="96"
length="16"
name="MESSAGE SECURITY CODE"
class="org.jpos.iso.IFA_BINARY"/>
<isofield
id="97"
length="17"
name="AMOUNT, NET SETTLEMENT"
class="org.jpos.iso.IFA_AMOUNT"/>
<isofield
id="98"
length="25"
name="PAYEE"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="99"
length="11"
name="SETTLEMENT INSTITUTION IDENT CODE"
class="org.jpos.iso.IFA_LLNUM"/>
<isofield
id="100"
length="11"
name="RECEIVING INSTITUTION IDENT CODE"
class="org.jpos.iso.IFA_LLNUM"/>
<isofield
id="101"
length="17"
name="FILE NAME"
class="org.jpos.iso.IFA_LLCHAR"/>
<isofield
id="102"
length="28"
name="ACCOUNT IDENTIFICATION 1"
class="org.jpos.iso.IFA_LLCHAR"/>
<isofield
id="103"
length="28"
name="ACCOUNT IDENTIFICATION 2"
class="org.jpos.iso.IFA_LLCHAR"/>
<isofield
id="104"
length="100"
name="TRANSACTION DESCRIPTION"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="105"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="106"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="107"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="108"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="109"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="110"
length="6"
name="RESERVED ISO USE"
class="org.jpos.iso.IFA_LLLNUM"/>
<isofield
id="111"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="112"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="113"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="114"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="115"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="116"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="117"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="118"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="119"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="120"
length="36"
name="RECORD DATA"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="121"
length="23"
name="S-121 BASE24-POS AUTH INDICATORS"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="122"
length="14"
name="S-122 CARD ISSUER IDENTIFICATION CODE"
class="org.jpos.iso.IFA_LLLNUM"/>
<isofield
id="123"
length="153"
name="S-123 CRYPTOGRAFIC SERVICE MESSAGE"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="124"
length="12"
name="S-124 DEPOSIT TYPE OR BATCH/SHIFT DATA"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="125"
length="255"
name="S-125 ATM ACCT INDICATOR OR POS SETTLEMENT DATA"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="126"
length="999"
name="S-126 ATM ADDIC. DATA OR POS PRE-AUTH/CHARGEBACK"
class="org.jpos.iso.IFA_LLLCHAR"/>
<isofield
id="127"
length="19"
name="SERVICE ID"
class="org.jpos.iso.IFA_LLLNUM"/>
<isofield
id="128"
length="16"
name="MAC 2"
class="org.jpos.iso.IFA_NUMERIC"/>
</isopackager>

Andrés Alcarraz

unread,

Jul 22, 2025, 10:31:24 AMJul 22

to jpos-...@googlegroups.com

Hi Vincent, then Murtuza is correct.

The ISO message is coming without the padding, the packager pads the field while packing the outgoing message, and then, the response come padded, so the mux doesn't match.

It is probably not happening to all message with white spaces because the others are probably coming already padded. You need to force the padding of the fields in the key before sending the message to the mux to fix the issue.

Andrés Alcarraz

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/89a2c3b8-34e3-4395-a0b2-672375696350n%40googlegroups.com.

Mark Salter

unread,

Jul 22, 2025, 2:02:53 PMJul 22

to jpos-...@googlegroups.com

I think this case is solved, so probably not need for a top dump trace at this time; at least until we sort out why you are not getting lots of failures.

--
Mark

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

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/89a2c3b8-34e3-4395-a0b2-672375696350n%40googlegroups.com.

signature.asc

Mark Salter

unread,

Jul 22, 2025, 2:11:35 PMJul 22

to jpos-...@googlegroups.com

Itnloks like it came through, perhaps just slowly.

Anyway therebisnsoecificbpricessing in QMUX forn11 and 41, so perhapsnitnis more forgiving for 11 and 41?

Check the QMUX.java source and get Key method in the version you are using to be sure.

If you are using the current version then field 11 and 41 are zero padded - which explains it working.
See : https://github.com/jpos/jPOS/blob/c25c5f13319dee573b5cc494f6eef8c68b6c9d57/jpos/src/main/java/org/jpos/q2/iso/QMUX.java#L283

Pad the matching field's values as you set them and all will be well.

--
Mark

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

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/949ae698-15ab-4b60-874c-43a536817695n%40googlegroups.com.

signature.asc

Alejandro Revilla

unread,

Jul 22, 2025, 3:28:23 PMJul 22

to jpos-...@googlegroups.com

Just a follow-up comment, we do pad field 41 and 11 in QMUX.getKey, but not field 37.

--

@apr

chhil

unread,

Jul 23, 2025, 12:36:03 AMJul 23

to jpos-...@googlegroups.com

Since 11 and 41 are being padded while creating the key used by QMUX.

https://github.com/jpos/jPOS/blob/main/jpos/src/main/java/org/jpos/q2/iso/QMUX.java#L267-L299

Your field 11 is 

<isofield
      id="11"
      length="6"
      name="SYSTEM TRACE AUDIT NUMBER"
      class="org.jpos.iso.IFA_NUMERIC"/>

Field 11 is zero padded by the qmux (6 length) and will be zero pad similarly by the pack operation as seen in the test case.

https://github.com/jpos/jPOS/blob/main/jpos/src/test/java/org/jpos/iso/IFA_NUMERICTest.java

Your field 41 is 

<isofield
      id="41"
      length="16"
      name="CARD ACCEPTOR TERMINAL IDENTIFICACION"
      class="org.jpos.iso.IF_CHAR"/>

Qmux pads its with 0's though, and channel pack will pad it with spaces, so the match won't be found. You need to make sure you pad your DE41 with spaces before setting it in the iso msg.

Your field 37 is 

<isofield
      id="37"
      length="12"
      name="RETRIEVAL REFERENCE NUMBER"
      class="org.jpos.iso.IF_CHAR"/>

QMUX will simply take what you have placed in DE37. Channel pack will pad it. So you need to make sure your field 37 is padded and 12 in length.

These paddings need to be done because of the use of the fields in the mux keys. Mux basically is not aware of what your field packagers are for the field and is trying to pad it using defaults which won't work across all types of field packagers.

-chhil

--

--
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/CAAgSK%3DnkMbWa7%2BB1kq8L2--2aL1uvsW%3DWqU2ODnUUTSCP3irkw%40mail.gmail.com.

Vincent

unread,

Jul 24, 2025, 9:06:52 PMJul 24

to jPOS Users

Hi Mark and Chhil,

I have attached my packager file that i used to the channel adaptor.

To add some context, only few of the transactions are ignored / failed, and most of the transaction has whitespace on field 41 and have no problems.
Thank you.

On Tuesday, July 22, 2025 at 7:01:15 PM UTC+7 Mark Salter wrote:

B24.xml

Vincent

unread,

Jul 24, 2025, 9:06:52 PMJul 24

to jPOS Users

Hi Mark and Chhil,

Below i attached the text content of the packager of field 11,37, and 41

<isofield
id="41"
length="16"

name="CARD ACCEPTOR TERMINAL IDENTIFICACION"
class="org.jpos.iso.IF_CHAR"/>

What i did on the code is just
subfield.set("37", " 001835" );
subfield.set("41", "00660109" );

the result will be just will be automatically padded to the length of the packager.

Also not every transaction with whitespaces are ignored, only very few of them are failed not readed by the MUX. Most of the transaction have whitespaces on field 41 and doing fine.

Thank you.

On Tuesday, July 22, 2025 at 7:01:15 PM UTC+7 Mark Salter wrote:

chhil

unread,

Jul 24, 2025, 9:16:04 PMJul 24

to jpos-...@googlegroups.com

Please read my response on what you need to do on 11,41,37.
I think you are concentrating on 41 and ignoring 37.

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/78df0dfc-e3f0-478f-8bb1-32401aa29f25n%40googlegroups.com.

Vincent

unread,

Jul 25, 2025, 1:30:28 PMJul 25

to jPOS Users

Hi chhil,

I will try your solution and try to update the result later.
Thank you.

Vincent

unread,

Jul 26, 2025, 7:51:42 AMJul 26

to jPOS Users

Hi chhil,
I did an investigation again for the problem, turns out i was giving false information before.
The field 37, 41 and 11 are already padded before i set the field.

It looks like this
subfield.set("37", "001835 " ); //12 digit length
subfield.set("41", "00660109 " );//16 digit length

Thats why, most of the transaction are successful, only few of them are received as timeout.
Are there any other suspect for this case?
Thank you.

Mark Salter

unread,

Jul 26, 2025, 7:56:49 AMJul 26

to jpos-...@googlegroups.com

Please simply ensure that these numeric fields are full of numeric digits and not spaces- i would expect the specification to detail this, please check that?

I believe this simple change will fix it.

--
Mark

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

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/14b6e3db-54d0-4b82-81bc-1e43b254a435n%40googlegroups.com.

signature.asc

Reply all

Reply to author

Forward

QMUX class unable to receive response from server - Intermittent

Vincent

Andrés Alcarraz

Mark Salter

Vincent

chhil

Mark Salter

murtuza chhil

Mark Salter

Mark Salter

Vincent

Vincent

Andrés Alcarraz

Mark Salter

Mark Salter

Alejandro Revilla

chhil

Vincent

Vincent

chhil

Vincent

Vincent

Mark Salter