QBean - Message response showing in channel listener but inaccessible in sending QBean

Goodangel.Matope

unread,

Jul 13, 2022, 10:36:42 AM7/13/22

to jPOS Users

I have the following server

with the following mux

<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="nfs-mux">
<in>nfs-receive</in>
<out>nfs-send</out>
<ready>nfs-channel.ready</ready>
<request-listener class="com.mypackage.MessageListener" logger="Q2" realm="incoming-request-listener">
<property name="queue" value="NFSTXNMGR" />
<property name="ctx.DESTINATION" value="nfs-mux" />
</request-listener>
</mux>

I also have this QBean

In the QBean Run method:

public void run () {
for (int tickCount=0; running (); tickCount++) {

QMUX qmux = (QMUX) NameRegistrar.getIfExists("mux.nfs-mux");
if (qmux != null) {
log.info("TransactionSendingBean: qmux is not null");
} else {
log.info("TransactionSendingBean: qmux is null, dangit!!");
}

if (qmux != null) {

try {
log.info("Transaction Sending Bean: qmux is not null");
if (qmux.isConnected()) {

ISOMsg transferMsg = new TransferMessage(destIIN, sourceAccount, destAccount, transferAmount);
log.info(common.messageDump(transferMsg));
ISOMsg trfResponse = qmux.request(transferMsg, 5000);
if (trfResponse!=null) {
if (trfResponse.hasField(39) && trfResponse.getValue("39").equals("000")) {
log.info("Transfer Transaction successful");
}
} else {
log.error("Response message is null");
}
}
}
catch (ISOException) {
logger.error("Exception Encountered: " + e.getMessage());
}
}
}
}

The weird behavior is that the response message does not return to the QBean from which i send it (I get "Response message is null") but the response is being received by the request listener class, as if it is a "new" message coming in over the channel and not a response to a message sent from the QBean. Any insights?

Mark Salter

unread,

Jul 13, 2022, 5:00:33 PM7/13/22

to jpos-...@googlegroups.com

What fields is you mix using to match the response to you request?

The default fields?

Are the fields actually echoed in the response to the request exactly?

--
Mark

Sent from ProtonMail mobile

-------- 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 on the web visit https://groups.google.com/d/msgid/jpos-users/0d79a54f-76ec-4d17-83ea-432fa4e9a159n%40googlegroups.com.

signature.asc

igor skljar

unread,

Jul 13, 2022, 6:16:12 PM7/13/22

to jPOS Users

Hi
Try to replace in server descriptor

<request-listener class=" com.mypackage.MessageListener" logger="Q2" realm="incoming-request-listener">
<property name="space" value="tspace:default" />
<property name="queue" value="NFSTXNMGR" />
<property name="ctx.DESTINATION" value="nfs-mux" />

</request-listener>

with

<in>nfs-send</in>
<out>nfs-receive</out>

среда, 13 июля 2022 г. в 17:36:42 UTC+3, Goodangel.Matope:

Goodangel.Matope

unread,

Jul 14, 2022, 1:07:44 AM7/14/22

to jPOS Users

The fields are matched exactly except for the MTI and field 39. I would have thought that this line

ISOMsg trfResponse = qmux.request(transferMsg, 5000);

would ensure that the response that comes back is assigned to the variable trfResponse.

Mark Salter

unread,

Jul 14, 2022, 1:17:38 AM7/14/22

to jpos-...@googlegroups.com

You did not share any message detail, they may not have matched or your mix default fields for matching could have been incorrect.

Either could have resulted in the timeout you described.

--
Mark

Sent from ProtonMail mobile

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/ffa986b6-511c-453a-94e6-926700072f7dn%40googlegroups.com.

signature.asc

Goodangel.Matope

unread,

Jul 14, 2022, 1:38:04 AM7/14/22

to jPOS Users

Sorry Mark,

Here are the messages: Outgoing

Incoming:

Thank you for your time

Mark Salter

unread,

Jul 14, 2022, 3:22:03 AM7/14/22

to jpos-...@googlegroups.com

On 14/07/2022 06:38, Goodangel.Matope wrote:
>
> Here are the messages: Outgoing
>
> <isomsg>
> <header>49534F383538332D31393933303231303030303030</header>
> <field id="0" value="1200"/>

...

> <field id="11" value="007402"/>

...

> <field id="41" value="000227"/>

...

> </isomsg>
>
> Incoming:
>
> <isomsg direction="incoming">
> 
> <header>49534F383538332D31393933303231303030303030</header>

...

> <field id="11" value="007402"/>

...

No 41?

> </isomsg>
>
>
Have you set your "key" element in your QMUX to override the default
matching? Sincey 41 is *not* present in the response, no match and time
out after 5 seconds.

Has this setup ever worked, or is it new?

--

Mark

signature.asc

Goodangel.Matope

unread,

Jul 14, 2022, 5:15:01 AM7/14/22

to jPOS Users

Hi Mark,

Sounds like adding the key is the key to my problem!

I have no idea where to set this key. And this is a new setup, it has not worked.

Thank you for your time

Goodangel

Mark Salter

unread,

Jul 14, 2022, 6:28:56 AM7/14/22

to jpos-...@googlegroups.com

Hi

On 14/07/2022 10:15, Goodangel.Matope wrote:
> I have no idea where to set this key. And this is a new setup, it has
> not worked.

MUX config : <key>nn xx yy</key> to match your interface field matching
criteria.

All in the Programmers guide - section 8.3.2. : "MTI mapping and default
key" - I hope you have and stated here for other's future reference.

--

Mark

signature.asc

Goodangel.Matope

unread,

Jul 14, 2022, 7:05:51 AM7/14/22

to jPOS Users

Thank you Mark, the key was the key to my problem, added a key as follows

just to see if it will work, and it has. So i will set up a more representative key once I have taken a good look at the messages going back and forth, and I have a good handle on the messages going back and forth.

Thank you for your invaluable time.

Reply all

Reply to author

Forward