Can't match request/reply on MTI 1460 / 1480 with only field 12 in common

[CharlelieBouvier]

Dear @tilln,

I still have timeout issue, and can't find how to fix it, tried multiple things...

Here are the logs, with request en unpacked reply :

2022-12-29 17:25:16,052 DEBUG o.a.j.t.TestBeanHelper: Setting fields=[DE0=1460, DE4=000000000500, DE12=221117162710, DE24=100, DE48=58000002000000003031313431333336333136323531353030343030, DE49=978, DE53=00, DE124=0FC008080800000061306534383337632D303830322D343932632D383033352D66626530353361373464623134313766333531652D636366362D343662342D613161622D6662333861343736643438333230323230383138303832343030303030303030303030333530555020434B444F2020202020202020202020202020202020202020202020202020202020202020203230313061626161326435332D613530622D346639322D386338652D346233383738653963373232] 2022-12-29 17:25:16,052 DEBUG o.a.j.t.TestBeanHelper: Setting timeout=5000 2022-12-29 17:25:16,052 DEBUG o.a.j.t.TestBeanHelper: Setting responseCodeField=39 2022-12-29 17:25:16,053 DEBUG o.a.j.t.TestBeanHelper: Setting successResponseCode=000 2022-12-29 17:25:16,053 DEBUG o.a.j.t.p.AbstractProperty: Running version, executing function 2022-12-29 17:25:16,053 DEBUG n.c.b.j.i.ISO8583Sampler: sampleStart 2022-12-29 17:25:16,095 DEBUG n.c.b.j.i.Q2: (channel/XXXXX) [connect] Try 0 XXXX 2022-12-29 17:25:16,095 DEBUG n.c.b.j.i.Q2: (packager) [pack] 3134363090100100000188000000000000000010303030303030303030353030323231313137313632373130313030303238580000020000000030313134313333363331363235313530303430303937383031003138360FC008080800000061306534383337632D303830322D343932632D383033352D66626530353361373464623134313766333531652D636366362D343662342D613161622D6662333861343736643438333230323230383138303832343030303030303030303030333530555020434B444F2020202020202020202020202020202020202020202020202020202020202020203230313061626161326435332D613530622D346639322D386338652D346233383738653963373232 2022-12-29 17:25:16,095 DEBUG n.c.b.j.i.Q2: (channel/XXXXXX) [send] Out: 1460 2022-12-29 17:25:16,181 DEBUG o.a.j.v.ViewResultsFullVisualizer: Expanded: [[Root]] 2022-12-29 17:25:16,181 DEBUG o.a.j.v.ViewResultsFullVisualizer: Elements: [Root] 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] 3134383000100000020100003232313131373136323731303030303033381400000000000000313431333336333136323531363030353230323231323239313732353136 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <bitmap>{12, 39, 48}</bitmap> 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <unpack fld="12" packager="org.jpos.iso.IFA_NUMERIC"> 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <value>221117162710</value> 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] </unpack> 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <unpack fld="39" packager="org.jpos.iso.IFA_NUMERIC"> 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <value>000</value> 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] </unpack> 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <unpack fld="48" packager="org.jpos.iso.IFA_LLLBINARY"> 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <value type='binary'>1400000000000000313431333336333136323531363030353230323231323239313732353136</value> 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (packager) [unpack] </unpack> 2022-12-29 17:25:16,237 DEBUG n.c.b.j.i.Q2: (channel/XXXXX) [receive] In: 1480

But I get a timeout, which seems to come from a request reply matching, so here is my configuration :

MTI MAPPING : "0123456789 0123456789 0022446769"

Mux Key configuration :
empty MTI : 12

Also tried to add :
1460 : 12
1480 : 12

But still, I have timeouts, what am I doing wrong please?

[tilln]

Hi @CharlelieBouvier

I can't immediately find anything wrong.

Would you mind posting the parts of the logs that show the XML deployment descriptors, just to double check your configuration?

[CharlelieBouvier]

Here are the requested logs :

2022-12-30 16:07:29,525 DEBUG o.a.j.t.TestBeanHelper: Setting mtiMapping=0123456789 0123456789 0022446769 2022-12-30 16:07:29,525 DEBUG o.a.j.t.TestBeanHelper: Setting muxKeyConfig=[1460:12, 1480:12, :12] 2022-12-30 16:07:29,525 DEBUG o.a.j.t.TestBeanHelper: Setting requestListener= 2022-12-30 16:07:29,525 DEBUG n.c.b.j.i.ISO8583Config: 'ISO8583 redressement Config' setting up QBeans jmeter-466a1a45 2022-12-30 16:07:29,525 DEBUG n.c.b.j.i.ISO8583Config: Deploying <qbean name="jmeter-466a1a45-channel" logger="Q2" class="org.jpos.q2.iso.OneShotChannelAdaptorMK2"><in>jmeter-466a1a45-send</in><out>jmeter-466a1a45-receive</out><max-connections>400</max-connections><channel name="jmeter-466a1a45" class="org.jpos.iso.channel.X25Channel" packager="org.jpos.iso.packager.GenericPackager" header="" logger="Q2"><property name="packager-config" value="XXXX.xml" /><property name="host" value="XXXXX" /><property name="port" value="5060" /><property name="packager-logger" value="Q2" /><property name="packager-realm" value="packager" /><property name="RETRY" value="0" /></channel></qbean> 2022-12-30 16:07:29,526 DEBUG n.c.b.j.i.ISO8583Config: Deploying <qmux name="jmeter-466a1a45-mux" logger="Q2"><in>jmeter-466a1a45-receive</in><out>jmeter-466a1a45-send</out><unhandled>jmeter-466a1a45-unhandled</unhandled><ready>jmeter-466a1a45.ready</ready><mtimapping>0123456789 0123456789 0022446769</mtimapping><key mti="1460">12</key><key mti="1480">12</key><key>12</key></qmux>

Thank you for your help

[tilln]

This all looks quite alright to me, though I'm not really a jPOS expert.
Also, I'm currently on holiday without access to a computer so can't reproduce your scenario.
Therefore I'd suggest you post a question in a jPOS forum such as the jPOS Users Google group .

[CharlelieBouvier]

Ok thank you, enjoy your holidays and I wish you a happy new year

[mchhil-incomm]

https://groups.google.com/g/jpos-users/c/uSYPjJaorQQ/m/YIcaa8jnBAAJ

Try using 0022446769 in third index of mti mapping.
The mapMti needs to produce the same result for request and response (so 1420 and 1430 both should produe 142 and similarly 1460 and 1480 should both produce 146).
When the request is sent, the mapped mti saved is 146, and when the response 1480 is received the mapped mti should result in 146.

    public static void main(String[] args) throws ISOException {

        String s1 = mapMTI("1460");
        String s2 = mapMTI("1480");

        if (s1.equals(s2)) {
            System.out.println("mapping works");
        }

    }

// JPOS code to map mti with some edits to make it work standalone.
    private static String mapMTI(String mti) throws ISOException {
        String   nomap      = "0123456789";
        String[] mtiMapping = new String[] { nomap, nomap, "0022446769" }; // <-- position 8 is a 6. 8 is the third position from the response 1480 and the 8 in the 3rd mtimapping needs to be changed to 6.

        StringBuilder sb = new StringBuilder();
        if (mti != null) {
            if (mti.length() < 4)
                mti = ISOUtil.zeropad(mti, 4); // #jPOS-55
            if (mti.length() == 4) {
                for (int i = 0; i < mtiMapping.length; i++) {
                    int c = mti.charAt(i) - '0';
                    if (c >= 0 && c < 10)
                        sb.append(mtiMapping[i].charAt(c));
                }
            }
        }
        return sb.toString();

    }

-chhil

[tilln]

I think the issue is due to how jPOS distinguishes requests and responses, by whether the third MTI digit is odd or even:

https://github.com/jpos/jPOS/blob/v2_1_6/jpos/src/main/java/org/jpos/iso/ISOMsg.java#L953-L955

    public boolean isRequest() throws ISOException {
        return Character.getNumericValue(getMTI().charAt (2))%2 == 0;
    }

Therefore your response with MTI 1480 gets "stuck" in the QMUX because it is considered a request.

Refer:
https://github.com/jpos/jPOS/blob/v2_1_6/jpos/src/main/java/org/jpos/q2/iso/QMUX.java#L203-L208
https://github.com/jpos/jPOS/blob/v2_1_6/jpos/src/main/java/org/jpos/q2/iso/QMUX.java#L223

    protected boolean isNotifyEligible(ISOMsg msg) {
        if (returnRejects)
            return true;

        try {
            return msg.isResponse();

Work-around may be to set the QMUX config flag "return-rejects" to true, however, this is not currently exposed by the JMeter plugin unfortunately.

Try the following:

1. Give your "ISO8583 redressement Config" a "Connection Reference/Identifier".
2. Programmatically set the Mux config flag "return-rejects" (that is not exposed by this plugin) e.g. in a Setup Thread Group with a Groovy Sampler:
   org.jpos.q2.iso.QMUX.getMUX('<INSERT-YOUR-CONNECTION-REFERENCE>-mux').returnRejects = true