QMUX Request Timeouts after 20 Seconds Even though Response is received!

[Rama Gullapalli]

My application connects to a server to send and receive responses using Channel Adaptor using QMUX. Below is the channel and mux definitions:

*********************** CHANNEL *********************************************

<?xml version="1.0" ?>

<channel-adaptor name='clientsimulator-adaptor'
    class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
    <channel class="com.google.PostChannel" name="client-channel"
             packager="org.jpos.iso.packager.GenericPackager" logger="Q2">
        <property name="packager-config" value="iso8583.xml" />
    </channel>
    <in>clientsimulator-send</in>
    <out>clientsimulator-receive</out>
    <reconnect-delay>30000</reconnect-delay>
    <ignore-iso-exceptions>yes</ignore-iso-exceptions>
</channel-adaptor>

**********************************************************************************
************************* MUX **************************************************
<?xml version="1.0" ?>

<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="clientsimulator-mux">
    <in>clientsimulator-receive</in>
    <out>clientsimulator-send</out>
    <unhandled>clientsimulator-unhandled</unhandled>
    <request-listener class="com.google.UnhandledMsgDriver" logger="Q2">
        <property name="registerId" value="UNHLD" />
    </request-listener>
</mux>
**********************************************************************************

Env:
     JDK : 1.7
     jPOS : 1.9.0
     App Server: JBoss 5.1

The above configuration works just fine in locally and also used to for the past few months(in production) until few days ago after a recent RedHat patch, the requests are timing out. Looking at the logs I see that the response is received by the jPos and Un-packaged but not handed to request thread. The request thread times out after 20 secs(default config). I've even tried to add the "key"s to the mux config to see if it is an issue with the match key, it did not help.

Thx!

[Alejandro Revilla]

Can you show us the log?

--

@apr

--
--
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
 
Join us in IRC at http://webchat.freenode.net/?channels=jpos
 
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
---
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/7dbce84a-3219-40ef-99d0-4915fa329d71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rama Gullapalli]

Below is the application log:

12:51:35,701  INFO STDOUT:? - <log realm="channel/IP:PORT" at="Mon Aug 22 12:51:35 CDT 2016.701">
12:51:35,701  INFO STDOUT:? -   <send>
12:51:35,701  INFO STDOUT:? -     <isomsg
12:51:35,701  INFO STDOUT:? - >
12:51:35,701  INFO STDOUT:? -       <field id="0" value="0200"/>
12:51:35,701  INFO STDOUT:? -       <field id="2" value="XXXXXXXXXXXXXXXX"/>
12:51:35,701  INFO STDOUT:? -       <field id="3" value="330000"/>
12:51:35,701  INFO STDOUT:? -       <field id="4" value="000000000000"/>
12:51:35,701  INFO STDOUT:? -       <field id="7" value="0822175135"/>
12:51:35,701  INFO STDOUT:? -       <field id="11" value="223297"/>
12:51:35,701  INFO STDOUT:? -       <field id="12" value="175135"/>
12:51:35,701  INFO STDOUT:? -       <field id="13" value="0822"/>
12:51:35,701  INFO STDOUT:? -       <field id="14" value="1908"/>
12:51:35,701  INFO STDOUT:? -       <field id="15" value="0822"/>
12:51:35,701  INFO STDOUT:? -       <field id="17" value="0822"/>
12:51:35,701  INFO STDOUT:? -       <field id="18" value="6999"/>
12:51:35,701  INFO STDOUT:? -       <field id="19" value="840"/>
12:51:35,701  INFO STDOUT:? -       <field id="22" value="062"/>
12:51:35,701  INFO STDOUT:? -       <field id="32" value="1100000939 "/>
12:51:35,701  INFO STDOUT:? -       <field id="37" value="110000223297"/>
12:51:35,701  INFO STDOUT:? -       <field id="41" value="TERMINALID"/>
12:51:35,701  INFO STDOUT:? -       <field id="42" value="               "/>
12:51:35,701  INFO STDOUT:? -       <field id="43" value="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"/>
12:51:35,701  INFO STDOUT:? -       <field id="49" value="840"/>
12:51:35,701  INFO STDOUT:? -       <field id="58" value="10101000211"/>
12:51:35,701  INFO STDOUT:? -       <field id="63" value="XXXXXXXX"/>
12:51:35,701  INFO STDOUT:? -       <field id="123" value="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"/>
12:51:35,701  INFO STDOUT:? -     </isomsg>
12:51:35,701  INFO STDOUT:? -     [B@7af56382
12:51:35,701  INFO STDOUT:? -   </send>
12:51:35,701  INFO STDOUT:? - </log>
12:51:36,437  INFO STDOUT:? - <log realm="channel/IP:PORT" at="Mon Aug 22 12:51:36 CDT 2016.437" lifespan="88185ms">
12:51:36,437  INFO STDOUT:? -   <receive>
12:51:36,437  INFO STDOUT:? -     <isomsg
12:51:36,437  INFO STDOUT:? - >
12:51:36,437  INFO STDOUT:? -       <field id="0" value="0210"/>
12:51:36,437  INFO STDOUT:? -       <field id="2" value="XXXXXXXXXXXXXXXX"/>
12:51:36,437  INFO STDOUT:? -       <field id="3" value="332000"/>
12:51:36,437  INFO STDOUT:? -       <field id="4" value="000000000000"/>
12:51:36,437  INFO STDOUT:? -       <field id="7" value="0822175135"/>
12:51:36,437  INFO STDOUT:? -       <field id="11" value="223297"/>
12:51:36,437  INFO STDOUT:? -       <field id="12" value="175135"/>
12:51:36,437  INFO STDOUT:? -       <field id="13" value="0822"/>
12:51:36,437  INFO STDOUT:? -       <field id="15" value="0822"/>
12:51:36,437  INFO STDOUT:? -       <field id="18" value="6999"/>
12:51:36,437  INFO STDOUT:? -       <field id="19" value="840"/>
12:51:36,437  INFO STDOUT:? -       <field id="32" value="1100000939 "/>
12:51:36,437  INFO STDOUT:? -       <field id="37" value="110000223297"/>
12:51:36,437  INFO STDOUT:? -       <field id="39" value="00"/>
12:51:36,437  INFO STDOUT:? -       <field id="41" value="TERMINALID"/>
12:51:36,437  INFO STDOUT:? -       <field id="49" value="840"/>
12:51:36,437  INFO STDOUT:? -       <field id="54" value="2002840C0000000070202001840C000000007020"/>
12:51:36,437  INFO STDOUT:? -       <field id="58" value="10101000211"/>
12:51:36,437  INFO STDOUT:? -       <field id="63" value="XXXXXXXX"/>
12:51:36,437  INFO STDOUT:? -       <field id="102" value="000008____3229"/>
12:51:36,437  INFO STDOUT:? -       <field id="123" value="TDAR01YCR01M"/>
12:51:36,437  INFO STDOUT:? -       <field id="126" value="0250828701000"/>
12:51:36,437  INFO STDOUT:? -       <field id="9999" value="1471888296437"/>
12:51:36,437  INFO STDOUT:? -     </isomsg>
12:51:36,437  INFO STDOUT:? -   </receive>
12:51:36,437  INFO STDOUT:? - </log>
12:51:36,437  INFO Logger:? - 0,<null>,com.company.driver,INFO,ISORequestHandler: received message
12:51:36,437 DEBUG Logger:? - 0,<null>,com.company.routing.core,DEBUG,get message processor for 0210                       
12:51:55,702 DEBUG Logger:? - 225,<null>,com.company.connector.registration.services,DEBUG, validatePAN-> result null
12:51:55,702 ERROR Logger:? - 225,<null>,com.company.connector.registration.services,ERROR,PAN validation failed

--

@apr

To unsubscribe, send email to jpos-users+...@googlegroups.com

For more options, visit this group at http://groups.google.com/group/jpos-users
---
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.

[Rama Gullapalli]

Quick update, restart of Application Server fixed the issue.

Thanks,
Rama

[Alejandro Revilla]

Then that's guaranteed to happen again. I hope you can isolate the logs of the problems so you can carefully try to understand why this happened.

--

@apr

[chhil]

Did you check if it ended up with the unhandled driver?

Your fields 11,41 match, so it shouldn't have, but worth taking a look at.

-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
 
Join us in IRC at http://webchat.freenode.net/?channels=jpos
 
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com

To unsubscribe, send email to jpos-users+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/jpos-users
---
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3DnT%3DEhvq6xYav_CR3tGKyZj%3Df7CU8X%2BSRjn8%3DV6eDLaQQ%40mail.gmail.com.

[Rama Gullapalli]

Yes, it ended up with the unhandled driver. Verified the match keys, default and custom, in both cases it failed to match. We had a similar problem in another clients env but that was resolved after reverting to single session ChannelAdaptor from 16 sessions MultiSessionChannelAdaptor. Verified the thread stack as well, couldnt find any clues there.

Thanks,
Rama

On Wednesday, August 24, 2016 at 7:15:20 PM UTC-7, chhil wrote:

Did you check if it ended up with the unhandled driver?

Your fields 11,41 match, so it shouldn't have, but worth taking a look at.

-chhil

On Thu, Aug 25, 2016 at 12:34 AM, Alejandro Revilla <a...@jpos.org> wrote:

Then that's guaranteed to happen again. I hope you can isolate the logs of the problems so you can carefully try to understand why this happened.

--

@apr

--
--
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
 
Join us in IRC at http://webchat.freenode.net/?channels=jpos
 
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com

To unsubscribe, send email to jpos-users+...@googlegroups.com

For more options, visit this group at http://groups.google.com/group/jpos-users
---
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.

[Rama Gullapalli]

Is there any additional logging that we can enable on the QMUX? We currently have the Q2 loggers enabled as shown in the config.

Thanks,
Rama

[Alejandro Revilla]

No, but if you have channel level logging you might be able to figure out what could be wrong with your messages.

--

@apr

To unsubscribe, send email to jpos-users+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/jpos-users
---
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/e111fd65-15ca-438f-b41d-87634acb7a4a%40googlegroups.com.

[Rama Gullapalli]

We have verified the messages and the match key DE are not the problem. The request(0200) and response(0210) logs are as attached in the email below with data masked.

Thanks,
Rama

--

@apr

[Mark Salter]

On 26/08/16 22:30, Rama Gullapalli wrote:
> We have verified the messages and the match key DE are not the problem.

If the response ended up in the unhandled queue, then they are the issue
- either by config, failure of the response to reach the mux through
which the request was sent or the message content. Or the MTI
request/response values do not align.

What fields have you configured your mux to match on?

> The request(0200) and response(0210) logs are as attached in the email
> below with data masked.

Sorry they did not make it to the mailing list.

Please present the 'keys' from the MUX config, the request and response
messages (in parsed form from the log and perhaps in raw if you can).

--
Mark

[chhil]

Are your IP/PORT intentionally removed in the logs? Mark raises a good point, if the request response are not on the same connection, it will go to the unhandled as it will see it as an unsolicited response.

12:51:35,701  INFO STDOUT:? - <log realm="channel/IP:PORT" at="Mon Aug 22 12:51:35 CDT 2016.701">

12:51:36,437  INFO STDOUT:? - <log realm="channel/IP:PORT" at="Mon Aug 22 12:51:36 CDT 2016.437" lifespan="88185ms">

The lifespan appears to be pretty large, usually the case when the channels logevent was created but hasn't received data and thus indicating idle time.

If the response came back on the same channel, I think such a large lifespan would not be visible.

-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

Join us in IRC at http://webchat.freenode.net/?channels=jpos

You received this message because you are subscribed to the  "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com

To unsubscribe, send email to jpos-users+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/jpos-users
---
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/182f3654-aaec-3621-3375-3d481d98faaf%40talktalk.net.

[Rama]

@chill, yes the IP and port are intentionally masked as the logs were from prod. The same config which was working for more than 4  months broke recently, and a restart fixed the issue. Again, no config changes were made. Few notes on the existing config, we have multiple channels defined talking to various server sockets with similar config(i.e different application modules talking to different IP/Ports). Only this particular channel app module was timing out.

Please find the logs displayed below:

12:51:35,701  INFO STDOUT:? - <log realm="channel/IP:PORT" at="Mon Aug 22 12:51:35 CDT 2016.701">

12:51:35,701  INFO STDOUT:? -   <send>
12:51:35,701  INFO STDOUT:? -     <isomsg

12:51:35,701  INFO STDOUT:? - >

12:51:35,701  INFO STDOUT:? -       <field id="0" value="0200"/>
12:51:35,701  INFO STDOUT:? -       <field id="2" value="XXXXXXXXXXXXXXXX"/>
12:51:35,701  INFO STDOUT:? -       <field id="3" value="330000"/>
12:51:35,701  INFO STDOUT:? -       <field id="4" value="000000000000"/>
12:51:35,701  INFO STDOUT:? -       <field id="7" value="0822175135"/>
12:51:35,701  INFO STDOUT:? -       <field id="11" value="223297"/>
12:51:35,701  INFO STDOUT:? -       <field id="12" value="175135"/>
12:51:35,701  INFO STDOUT:? -       <field id="13" value="0822"/>
12:51:35,701  INFO STDOUT:? -       <field id="14" value="1908"/>
12:51:35,701  INFO STDOUT:? -       <field id="15" value="0822"/>
12:51:35,701  INFO STDOUT:? -       <field id="17" value="0822"/>
12:51:35,701  INFO STDOUT:? -       <field id="18" value="6999"/>
12:51:35,701  INFO STDOUT:? -       <field id="19" value="840"/>
12:51:35,701  INFO STDOUT:? -       <field id="22" value="062"/>
12:51:35,701  INFO STDOUT:? -       <field id="32" value="1100000939 "/>
12:51:35,701  INFO STDOUT:? -       <field id="37" value="110000223297"/>
12:51:35,701  INFO STDOUT:? -       <field id="41" value="TERMINALID"/>
12:51:35,701  INFO STDOUT:? -       <field id="42" value="               "/>
12:51:35,701  INFO STDOUT:? -       <field id="43" value="

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"/>
12:51:35,701  INFO STDOUT:? -       <field id="49" value="840"/>
12:51:35,701  INFO STDOUT:? -       <field id="58" value="10101000211"/>
12:51:35,701  INFO STDOUT:? -       <field id="63" value="XXXXXXXX"/>
12:51:35,701  INFO STDOUT:? -       <field id="123" value="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"/>

12:51:35,701  INFO STDOUT:? -     </isomsg>
12:51:35,701  INFO STDOUT:? -     [B@7af56382
12:51:35,701  INFO STDOUT:? -   </send>
12:51:35,701  INFO STDOUT:? - </log>

12:51:36,437  INFO STDOUT:? - <log realm="channel/IP:PORT" at="Mon Aug 22 12:51:36 CDT 2016.437" lifespan="88185ms">

12:51:36,437  INFO STDOUT:? -   <receive>
12:51:36,437  INFO STDOUT:? -     <isomsg

12:51:36,437  INFO STDOUT:? - >

1. Take notice of the highlighted statements. The point at which the response thread was received and after which the app thread timed out after 20 seconds.
2. The default key config was used in the QMUX i.e 11 and 41. As you can see from the logs, the request and response keys match.

@chhil, could you please clarify the below statement in more detail :

"The lifespan appears to be pretty large, usually the case when the channels logevent was created but hasn't received data and thus indicating idle time.

If the response came back on the same channel, I think such a large lifespan would not be visible."

From the app logs, the response was immediately received in a second.

Thanks,
Rama

- show quoted text -

To unsubscribe, send email to jpos-users+...@googlegroups.com

For more options, visit this group at http://groups.google.com/group/jpos-users
---
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.

[chhil]

I understand that the response was received immediately, my concern is, it was possibly received on a channel that did not send the request.

Configuration does not have to do anything with it. 

In this case the keys for the mux are fine but the mux that sent request has the match key and the mux that received the response doesn't hence it ended up in the unhandled.

So do check if 

1.the port numbers to verify it was on the same channel

2.the channel name in the log on which the request was sent and on which the response was received.

Lifespan Clarification :

Do read up on http://jpos.org/blog/2013/01/logger-lifespan-attribute/

The following is quoted from the blog.

​

So depending on the code using the logger, the meaning of the ‘lifespan’ attribute vary. 
In the ChannelAdaptor for example, we create a LogEvent, and then call channel.receive(), so the ‘lifespan’ attribute basically shows us 
how much time the channel was idle and we were waiting for a message to come.
 In order to understand the lifespan attribute, you need to take a look at the code that generates it.

​

So what the lifespan from your log hints at is, the receive part of the channel was idle for quite some time and likely not receiving anything for the duration from it events creation.

Which leads me to believe the receiver wasn't active in the system and all of a sudden it got a response.

-chhil

To unsubscribe, send email to jpos-users+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/jpos-users
---
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/4cb2f2ff-a2d4-441c-95cb-5fdea4fe6599%40googlegroups.com.

[Rama]

I've confirmed from the logs again, the IP and port in both request and response are same. You bring up a point on the lifespan, will look into it further. We have a single channel session that is used for all the app threads. Could this be related to using the default space for all the client channels that belong to different app modules?

Thanks,
Rama

On Sunday, August 28, 2016 at 8:41:39 PM UTC-7, chhil wrote:

I understand that the response was received immediately, my concern is, it was possibly received on a channel that did not send the request.

Configuration does not have to do anything with it. 

In this case the keys for the mux are fine but the mux that sent request has the match key and the mux that received the response doesn't hence it ended up in the unhandled.

So do check if 

1.the port numbers to verify it was on the same channel

2.the channel name in the log on which the request was sent and on which the response was received.

Lifespan Clarification :

Do read up on http://jpos.org/blog/2013/01/logger-lifespan-attribute/

The following is quoted from the blog.

​

So depending on the code using the logger, the meaning of the ‘lifespan’ attribute vary. 
In the ChannelAdaptor for example, we create a LogEvent, and then call channel.receive(), so the ‘lifespan’ attribute basically shows us 
how much time the channel was idle and we were waiting for a message to come.
 In order to understand the lifespan attribute, you need to take a look at the code that generates it.

​

So what the lifespan from your log hints at is, the receive part of the channel was idle for quite some time and likely not receiving anything for the duration from it events creation.

Which leads me to believe the receiver wasn't active in the system and all of a sudden it got a response.

-chhil

[chhil]

We have a single channel session…

​

If you have a single channel then its its not possible to get a response on anything but that channel.

Could this be related to using the default space for all the client channels that belong to different app modules?

​

I don't have sufficient knowledge to answer this, hopefully someone in this group with a better understanding of the internals can assist you here.

-chhil

To unsubscribe, send email to jpos-users+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/jpos-users
---
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/62ae4c8f-8fb2-4065-9fe3-99425df4fef7%40googlegroups.com.

[Mark Salter]

On 29/08/16 00:30, Rama wrote:
> yes the IP and port are intentionally masked as the logs were
> from prod.

Do you hold a commercial license for using jpos?

> The same config which was working for more than 4 months
> broke recently,

What changed recently?

> and a restart fixed the issue.

Not fixed, but stopped happening I guess you mean.

> Again, no config changes were made.

What other changes occurred, if nothing jPOS related changed, then you
need to look elsewhere.

> Few notes on the existing config, we have multiple channels
> defined talking to various server sockets with similar config(i.e
> different application modules talking to different IP/Ports). Only this
> particular channel app module was timing out.

So you need to work out what is different about this connection or other
system.

--
Mark

[Mark Salter]

On 29/08/16 09:13, Rama wrote:
> Could this be related to using the default space for all the client
> channels that belong to different app modules?

Without knowing how you are using this (perhaps) single space across
your client's how would we know?

Are you sharing space keys between components?

Are any other connections reporting an unhandled response message?

--
Mark

[Mark Salter]

On 24/08/16 01:20, Rama Gullapalli wrote:
> until few days ago after a recent RedHat patch

What was patched?

Unpatch it?

--
Mark

[Rama]

1. Yes , we have a commercial JPOS license.
2. No other connections are reporting unhandled response message.
3. We are using default space for all the client channel adaptors defined in the system.

Thanks!

[Mark Salter]

On Tuesday, August 30, 2016 at 6:40:23 AM UTC+1, Rama wrote:

1. Yes , we have a commercial JPOS license.

Great.  With support?
 

2. No other connections are reporting unhandled response message.

Then your matching process/config is broken/misconfigured.
 

3. We are using default space for all the client channel adaptors defined in the system.

Do you have any name collisions, with different deployed components using a single in/out queue and causing a race condition or conflict?
Are you generating any space queues - are their names unique enough?

--
Mark

[Rama]

1. Yes , we have a commercial JPOS license.

Great.  With support?

    Not sure, need to check on that.
 

2. No other connections are reporting unhandled response message.

Then your matching process/config is broken/misconfigured.

    We are using similar config for all channels.

3. We are using default space for all the client channel adaptors defined in the system.

Do you have any name collisions, with different deployed components using a single in/out queue and causing a race condition or conflict?
Are you generating any space queues - are their names unique enough?

   We are not explicitly defined any space queues, I believe this results in using default ones.

--
Mark

[Mark Salter]

On 01/09/16 00:56, Rama wrote:
> 3. We are using default space for all the client channel
> adaptors defined in the system.
>
> Do you have any name collisions, with different deployed components
> using a single in/out queue and causing a race condition or conflict?
> Are you generating any space queues - are their names unique enough?
>
> We are not explicitly defined any space queues, I believe this
> results in using default ones.

But the space in/out queues across the QBeans deployed are not the same?

[Rama]

Recent developments on the same issue, it reoccurred recently. Had to restart the App Server as a work around for now. Tried additional logging in QMUX of the space entries before the request is sent and after the response is received.

23 Feb 2017 11:21:07,778 DEBUG Logger:? - 1155,<null>,com.company.jpos,DEBUG,QMUX : request : Space : tspace:switch1 -  <key count='1'>clientsimulator-switch1-adaptor.ready</key>
<key count='1'>clientsimulator-switch1-receive</key>
<key count='1'>clientsimulator-switch1-send.0200000000000810001334327.req</key>
<key count='0'>clientsimulator-switch1-send</key> <keycount>3</keycount>  <gcinfo>0,0</gcinfo>
23 Feb 2017 11:21:07,779  INFO STDOUT:? - <log realm="channel/10.84.40.23:2172" at="Thu Feb 23 11:21:07 CST 2017.779" lifespan="1ms">
23 Feb 2017 11:21:07,779  INFO STDOUT:? -   <send>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -     <isomsg
23 Feb 2017 11:21:07,779  INFO STDOUT:? - >
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="0" value="0200"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="2" value="xxxxxxxxxxxx0001"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="3" value="310000"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="4" value="000000000000"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="7" value="0223172107"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="11" value="334327"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="12" value="172107"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="13" value="0223"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="14" value="1806"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="15" value="0223"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="17" value="0223"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="18" value="6999"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="19" value="840"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="22" value="012"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="32" value="1100000816 "/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="37" value="110000334327"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="41" value="810001  "/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="42" value="               "/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="43" value="ClientName                           FLUS"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="49" value="840"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="58" value="10101000211"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -       <field id="123" value="TDAV2167501    20 w 2nd AveCV0511510"/>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -     </isomsg>
23 Feb 2017 11:21:07,779  INFO STDOUT:? -     [B@71ede81c
23 Feb 2017 11:21:07,779  INFO STDOUT:? -   </send>
23 Feb 2017 11:21:07,779  INFO STDOUT:? - </log>
23 Feb 2017 11:21:07,923  INFO STDOUT:? - <log realm="channel/10.84.40.23:2172" at="Thu Feb 23 11:21:07 CST 2017.922" lifespan="372050ms">
23 Feb 2017 11:21:07,923  INFO STDOUT:? -   <receive>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -     <isomsg
23 Feb 2017 11:21:07,923  INFO STDOUT:? - >
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="0" value="0210"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="2" value="530406______0022"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="3" value="310000"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="4" value="000000000000"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="7" value="0223172107"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="11" value="334327"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="12" value="172107"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="13" value="0223"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="15" value="0223"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="18" value="6999"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="22" value="012"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="32" value="1100000816"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="37" value="110000334327"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="39" value="14"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="41" value="810001  "/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="49" value="840"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="58" value="10101000211"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="63" value="E0      DCI   "/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="113" value="59236073872"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="123" value="TDAR01S"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -       <field id="9999" value="1487870467922"/>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -     </isomsg>
23 Feb 2017 11:21:07,923  INFO STDOUT:? -   </receive>
23 Feb 2017 11:21:07,923  INFO STDOUT:? - </log>
23 Feb 2017 11:21:07,924 DEBUG Logger:? - 0,<null>,com.company.jpos,DEBUG,QMUX : processUnhandled : Space : tspace:switch1 -  <key count='1'>clientsimulator-switch1-adaptor.ready</key>
<key count='1'>clientsimulator-switch1-receive</key>
<key count='1'>clientsimulator-switch1-send.0200000000000810001334327.req</key> <keycount>2</keycount>  <gcinfo>0,0</gcinfo>

/*******************************         After application thread timesout - 20 seconds (current configuration)
23 Feb 2017 11:21:27,778 DEBUG Logger:? - 1155,<null>,com.company.jpos,DEBUG,QMUX : response : Space : tspace:switch1 -  <key count='1'>clientsimulator-switch1-unhandled</key>
<key count='1'>clientsimulator-switch1-adaptor.ready</key>
<key count='1'>clientsimulator-switch1-receive</key> <keycount>2</keycount>  <gcinfo>1,0</gcinfo>

/******************************* SUCCESS CASE *************************************************************/
23 Feb 2017 12:52:28,396  INFO STDOUT:? - <log realm="channel/10.84.40.23:2172" at="Thu Feb 23 12:52:28 CST 2017.396">
23 Feb 2017 12:52:28,396  INFO STDOUT:? -   <send>
23 Feb 2017 12:52:28,396  INFO STDOUT:? -     <isomsg
23 Feb 2017 12:52:28,396  INFO STDOUT:? - >
23 Feb 2017 12:52:28,396  INFO STDOUT:? -       <field id="0" value="0200"/>
23 Feb 2017 12:52:28,396  INFO STDOUT:? -       <field id="2" value="530406______0012"/>
23 Feb 2017 12:52:28,396  INFO STDOUT:? -       <field id="3" value="310000"/>
23 Feb 2017 12:52:28,396  INFO STDOUT:? -       <field id="4" value="000000000000"/>
23 Feb 2017 12:52:28,396  INFO STDOUT:? -       <field id="7" value="0223185228"/>
23 Feb 2017 12:52:28,396  INFO STDOUT:? -       <field id="11" value="603771"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="12" value="185228"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="13" value="0223"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="14" value="1806"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="15" value="0223"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="17" value="0223"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="18" value="6999"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="19" value="840"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="22" value="012"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="32" value="1100000816 "/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="37" value="110000603771"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="41" value="810001  "/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="42" value="               "/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="43" value="ClientName                           FLUS"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="49" value="840"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="58" value="10101000211"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -       <field id="123" value="TDAV2167501    20 w 2nd AveCV0511222"/>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -     </isomsg>
23 Feb 2017 12:52:28,397  INFO STDOUT:? -     [B@7db16f1c
23 Feb 2017 12:52:28,397  INFO STDOUT:? -   </send>
23 Feb 2017 12:52:28,397  INFO STDOUT:? - </log>
23 Feb 2017 12:52:28,399 DEBUG Logger:? - 860,<null>,com.company.jpos,DEBUG,QMUX : request : Space : tspace:switch1 -  <key count='1'>clientsimulator-switch1-adaptor.ready</key>
<key count='1'>clientsimulator-switch1-send.0200000000000810001603771.req</key> <keycount>1</keycount>  <gcinfo>0,0</gcinfo>
23 Feb 2017 12:52:41,619  INFO STDOUT:? - <log realm="channel/10.84.40.23:2172" at="Thu Feb 23 12:52:41 CST 2017.619" lifespan="292234ms">
23 Feb 2017 12:52:41,619  INFO STDOUT:? -   <receive>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -     <isomsg
23 Feb 2017 12:52:41,619  INFO STDOUT:? - >
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="0" value="0210"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="2" value="530406______0012"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="3" value="312000"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="4" value="000000000000"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="7" value="0223185228"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="11" value="603771"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="12" value="185228"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="13" value="0223"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="15" value="0223"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="18" value="6999"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="22" value="012"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="32" value="1100000816"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="37" value="110000603771"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="38" value="500417"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="39" value="00"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="41" value="810001  "/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="49" value="840"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="58" value="10101000211"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="63" value="E0      DCI   "/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="102" value="203012345"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="113" value="59236073872"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="123" value="TDAR01YCR01M"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -       <field id="9999" value="1487875961618"/>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -     </isomsg>
23 Feb 2017 12:52:41,619  INFO STDOUT:? -   </receive>
23 Feb 2017 12:52:41,619  INFO STDOUT:? - </log>
23 Feb 2017 12:52:41,620 DEBUG Logger:? - 860,<null>,com.company.jpos,DEBUG,QMUX : response : Space : tspace:switch1 -  <key count='1'>clientsimulator-switch1-adaptor.ready</key> <keycount>0</keycount>  <gcinfo>0,0</gcinfo>

[Andrés Alcarraz]

For some reason I cannot figure out your response didn't match your request key.

Here is the evidence bolded and underlined.

There is little more I (and I guess the rest of us simple mortals) can do with the data you provided. Your response is processed as unhandled as soon as it arrives

Best regards

El 23/02/17 a las 17:22, Rama escribió:

[Rama]

Andres,

Appreciate taking a dig at it. I understand it is getting processed as Unhandled message but why even though the match keys between request and response are right. Hence we added additional logs to print the Space entries to see if it sheds any light on this.

Thanks,
Rama

[Andrés Alcarraz]

which fields are you using as key?

El 23/02/17 a las 18:26, Rama escribió:

--
--
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 post to this group, send email to jpos-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/c2f86aa3-e64a-4804-b6b5-25cc4bb90ba4%40googlegroups.com.

[Rama]

11,41

[Andrés Alcarraz]

Hi Rama, the only explanation I can find is that the internal space could somehow end pointing to two different instances at input time than at output time.

Can you share your QMUX setup/config file? It seems that you are setting the reuse property to true, I don't know why or how yet but that could be being an issue.

El 23/02/17 a las 18:39, Rama escribió:

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/6389af1e-2efc-4b1e-b412-dd40f320f954%40googlegroups.com.

[Rama]

Channel :

<channel-adaptor name='clientsimulator-switch1-adaptor'
    class="com.company.jpos.ChannelAdaptor" logger="Q2">
    <channel class="com.ondot.driver.MyPostChannel" name="client-switch1-channel"
             packager="org.jpos.iso.packager.GenericPackager" logger="Q2">
        <property name="packager-config" value="switch1.xml" />
    </channel>
    <in>clientsimulator-switch1-send</in>
    <out>clientsimulator-switch1-receive</out>
    <reconnect-delay>30000</reconnect-delay>
    <ignore-iso-exceptions>yes</ignore-iso-exceptions>
    <space>tspace:switch1</space>
</channel-adaptor>

QMUX:

<mux class="com.company.jpos.QMUX" logger="Q2" name="clientsimulator-switch1-mux">
    <in>clientsimulator-switch1-receive</in>
    <out>clientsimulator-switch1-send</out>
    <unhandled>clientsimulator-switch1-unhandled</unhandled>
    <space>tspace:switch1</space>
    <request-listener class="com.company.jpos.UnhandledMsgDriver" logger="Q2">
        <property name="Network" value="SWITCH1" />
        <property name="registerId" value="UNHLD" />
    </request-listener>
</mux>

Env: JDK7, jPos 1.9.0, JBoss 5.1 GA App Server

[Mark Salter]

On 23/02/17 20:22, Rama wrote:
> Recent developments on the same issue, it reoccurred recently. Had to
> restart the App Server as a work around for now. Tried additional
> logging in QMUX of the space entries before the request is sent and
> after the response is received.

Your processing seems very wrong, a couple of questions...

1) Why is the PAN in the response different from that in the request?
2) Why is is :-

<log> realm="channel/10.84.40.23:2172"at="Thu Feb 23 11:21:07 CST>

2017.922"lifespan="*372050ms*">
> 23Feb201711:21:07,923 INFO STDOUT:?- <receive>
.
.
.
> 23Feb201712:52:41,619 INFO STDOUT:?-<log> realm="channel/10.84.40.23:2172"at="Thu Feb 23 12:52:41 CST> 2017.619"lifespan="*292234ms*">
> 23Feb201712:52:41,619 INFO STDOUT:?- <receive>

That lifespan feels odd.

3) The decline (unknown card I guess) fails and the approval works. you
have any problems parsing all the fields, are you leaving anything from
one response (or send) that is interfering with the next action on the
Channel?

4) Thus does your Channel precisely match the target?
5) Does the Packager precisely match the target?
6) what does <null> here indicate ? :-

23 Feb 2017 11:21:07,778 DEBUG Logger:? -
1155,<null>,com.company.jpos,DEBUG,QMUX : request : Space :
tspace:switch1 - <key count='1'>clientsimulator-switch1-adaptor.ready</key>

--
Mark

[Rama]

  > Recent developments on the same issue, it reoccurred recently. Had to

> restart the App Server as a work around for now. Tried additional
> logging in QMUX of the space entries before the request is sent and
> after the response is received.

Your processing seems very wrong, a couple of questions...

1) Why is the PAN in the response different from that in the request?

   >>PAN is right and verified just not modified while posting.

2) Why is is :-

<log> realm="channel/10.84.40.23:2172"at="Thu Feb 23 11:21:07 CST>
2017.922"lifespan="*372050ms*">
> 23Feb201711:21:07,923 INFO STDOUT:?-  <receive>

> 23Feb201712:52:41,619 INFO STDOUT:?-<log> realm="channel/10.84.40.23:2172"at="Thu Feb 23 12:52:41 CST> 2017.619"lifespan="*292234ms*">
> 23Feb201712:52:41,619 INFO STDOUT:?-  <receive>

That lifespan feels odd.

    >>I'm not sure why the lifespan is so high. According to the logs, response is received in less than 300 ms.

3) The decline (unknown card I guess) fails and the approval works.  you
have any problems parsing all the fields, are you leaving anything from
one response (or send) that is interfering with the next action on the
Channel?

>>All the fields are being parsed.

4) Thus does your Channel precisely match the target?

    >>Target?

5) Does the Packager precisely match the target?

    >>Target?

6) what does <null> here indicate ? :-
23 Feb 2017 11:21:07,778 DEBUG Logger:? -
1155,<null>,com.company.jpos,DEBUG,QMUX : request : Space :
tspace:switch1 -  <key count='1'>clientsimulator-switch1-adaptor.ready</key>

>>"null" indicates Response not being matched to the right Request application thread.

Thanks,
Rama

[Rama]

Mark,

quick note on the lifespan. Even local testing I see large numbers like xxxxxxms. But when you look at the timestamp which has the "ms" too and the difference is less than 300ms.

SEND

23 Feb 2017 11:21:07,779  INFO STDOUT:? - <log realm="channel/10.84.40.23:2172" at="Thu Feb 23 11:21:07 CST 2017.779" lifespan="1ms">

Receive
23 Feb 2017 11:21:07,923  INFO STDOUT:? - <log realm="channel/10.84.40.23:2172" at="Thu Feb 23 11:21:07 CST 2017.922" lifespan="372050ms">

Thanks,
Rama

[Andrés Alcarraz]

I think the lifespan in the receive log is high because the log event is created when the receive is invocated, which can be long before the message arrives.

Regards

El 24/02/17 a las 17:33, Rama escribió:

--

--
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 post to this group, send email to jpos-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/f02addb4-b7a5-4808-9ee2-f7f577d833a3%40googlegroups.com.

[Alejandro Revilla]

That is correct, it's useful as an indication about how long the channel was idle before receiving a message.

--

@apr

[Mark Salter]

Your in-line responding is as broken as your MUX setup :-(

I will try and work out how you replied and reply back.

In summary and in advance of the replies,

The software you are using does not give this result for others, so it
is likely something you have set-up incorrectly or misunderstood and now
can't see.

You are going to need to forget all your assumptions and to a degree
start from scratch with a smart question.

Try and start from a position of :-

jPOS works for 100s of systems for billions of request/response pairs
each day every day; what is wrong with my system implementation.

So :-

1) have you check and double checked that the Channel is putting and
receiving the auth messages to and from the wire correctly

2) Does the Packager fully match the specification of the interface you
are exchanging messages with?

3) Please anonymise examples to maintain their integrity - you need to
do the considered 'hard' work here so that we can help.

4) How many connections do you have with this interface

5) If multiple connections - how are they pooled?

6) Why didn't this issue turn up in your testing? What is different in
that environment?

7) How many java vms do you have - are the space instances on the send
and receive actually a single space at all times?

8) What QBeans do you have deployed, how are you starting them?

On 24/02/17 20:28, Rama wrote:
>> 1) Why is the PAN in the response different from that in the request?
>>
> PAN is right and verified just not modified while posting.

You modified the request but not the response? in one 'example' but not
the other?

> I'm not sure why the lifespan is so high. According to the logs,
> response is received in less than 300 ms.

As long as it actually matches yes?

>> 3) The decline (unknown card I guess) fails and the approval works.
>> you
>> have any problems parsing all the fields, are you leaving anything from
>> one response (or send) that is interfering with the next action on the
>> Channel?
> All the fields are being parsed.

I want to check all of the bytes on the Channel are being, and that you
have checked that the Channel and Packager precisely matches the system
to which you are sending your requests.

>> 4) Thus does your Channel precisely match the target?
>>
> Target?

The system you are sending your requests to and getting responses from.

>>
>> 5) Does the Packager precisely match the target?
>>
> Target?

See above.

--
Mark

[Mark Salter]

On 25/02/17 09:39, 'Mark Salter' via jPOS Users wrote:
> Your in-line responding is as broken as your MUX setup :-(
>
> I will try and work out how you replied and reply back.

A lot of manual editing, but it looks like I got there!

--
Mark