Not getting response with mux
Horacio Estigarribia
tried using channel.send() and channel.receive(), when I take this
approach I get a response fine, but if the server is unavailable the
channel.receive() stays open and I want it to close after 60seconds.
Instead I tried mux.request(m, 60000), but it always returns null, any
ideas? Thanks
((LogSource)channel).setLogger (logger, "test-channel");
channel.connect();
ISOMsg m = new ISOMsg();
ISOMUX mux = new ISOMUX(channel);
m.setMTI("0200");
m.set ( X, "XXXX");
......
channel.send(m);
ISOMsg r = mux.request(m, 60000); // r comes always null
David Bergert
Does your 200 message have fields 11 and 41 set ? If it doesn't it would be
able to "find" the transaction using this key. but you can override the MUX
key to a unique value if the default of 11,41 does not work for you.
David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com
Mark Salter
> I tried mux.request(m, 60000), but it always returns null, any
> ideas?
a response. Does it take 60 seconds to return this despite a traceable
exchange occurring?
Are you calling ISOMUX.setTraceNumberField(int) at all?
Does your request have fields 41 and 11, does your response have these
fields with the *same* content meaning whoever is replying is echoing
the values back in these fields?
Can you show us the request/response pair, the log detail from the
channel would be good.
Adding your Logger to the ISOMUX will also show you more detail - as you
get going.
You don't show that you are giving the ISOMsg a packager, which are you
using? Adding the Logger to the packager will show almost all the
detail of your exchange and might help you (and us) see what is happening.
>
> ((LogSource)channel).setLogger (logger, "test-channel");
> channel.connect();
You don't need to do anything with the channel apart from give one to
the ISOMUX. ISOMUX will take care of the channel.
>
> ISOMsg m = new ISOMsg();
> ISOMUX mux = new ISOMUX(channel);
As above - any packager?
>
> m.setMTI("0200");
> m.set ( X, "XXXX");
> ......
>
> channel.send(m);
The above line is not required...
> ISOMsg r = mux.request(m, 60000); // r comes always null
...the method call above sends the message to the given channel and
gathers the response, by matching request.41+request.11 to
response.41+response.11.
You are currently sending two requests to you target system, and
probably don't want that.
--
Mark
Horacio Estigarribia
for trace number, using field 11 (see below), but the timeout still
occurs after 60 seconds and I get a null exception when I try to print
field 39, this is because the string is null of course, which means
I'm not getting a response?
Is there a way to tell the channel.response() method to stop after X
second? I know that working directly with the channel is not the best
thing, but it's proven to be working now, the only problem comes when
there's no response from the channel and it just stays listening.
Thanks
Logger logger = new Logger();
logger.addListener(new SimpleLogListener(System.out));
ISOChannel channel = new ASCIIChannel (
"192.168.1.1", 10000, new ISOASCIIPackager());
((LogSource)channel).setLogger (logger, "test-channel");
ISOMUX mux = new ISOMUX(channel);
ISOMsg m = new ISOMsg();
m.set ( X, "XXXXXX");
....
mux.setTraceNumberField(11);
ISOMsg r = mux.request(m, 60000);
Mark Salter
> Yes I'm getting the same value in my response
> for trace number, using field 11 (see below), but the timeout still
> occurs after 60 seconds and I get a null exception when I try to print
> field 39, this is because the string is null of course, which means
check please, the difference is important.
Perhaps you are getting a reject because of the duplicate you were
sending, although it seems you have stopped that now.
> I'm not getting a response?
Set Loggers all through as indicated previously, so you can see what is
happening, and can if you want let us see.
>
> Is there a way to tell the channel.response() method to stop after X
> second? I know that working directly with the channel is not the best
> thing, but it's proven to be working now, the only problem comes when
> there's no response from the channel and it just stays listening.
It all works, it is all proven, there is nothing to work around you just
need to help us help you and complete the checks ask and provide the
detail requested (or say you cannot).
Dealing with the channel directly may lead you into more problems...
Please check, posting here if possible...
A trace of the request and response,
On request and response:-
Check the MTI is 0200 on the request and 0210 on the response,
check field 41 is identical in both,
check field 11 - no need to set it as 11 is the default - is identical
in both.
And a Logger to our ISOMUX and to your packager, you may have other
problems preventing your flow.
--
Mark
Horacio Estigarribia
missing something and get back to you as soon as I get the loggers in
place.
Horacio Estigarribia
the code:
Logger logger = new Logger();
logger.addListener(new SimpleLogListener(System.out));
ISOChannel channel = new ASCIIChannel (
ISOMUX mux = new ISOMUX(channel);
mux.setLogger (logger, "mux");
ISOMsg m = new ISOMsg();
ISORequest r = new ISORequest(m);
mux.queue(r);
ISOMsg res = r.getResponse(15000);
if (res != null){
System.out.println("MTI: " + res.getMTI().toString());
System.out.println("RESPUESTA: " + res.getString(39));
System.out.println("11: " + res.getString(11));
System.out.println("41: " + res.getString(41));
} else {
System.out.println("timeout");
}
channel.disconnect();
But here's the output when I run it:
<log realm="mux" at="Mon Feb 16 09:58:19 PYST 2009.663">
<mux>
<mux-stats connected="true">
Connections: 1
TX messages: 0
TX expired: 0
TX pending: 1
RX messages: 0
RX expired: 0
RX pending: 0
RX unmatched: 0
RX forwarded: 0
</mux-stats>
</mux>
</log>
MTI: 0200
RESPUESTA: null
11: 134396
41: IVR00001
Why am I getting a 0200 in response? I know the request is going out
but I don't know why I'm not getting a 0210 and why is not treating it
as a null response.
Mark Salter
> Hello, I did some changes so I don't use the channel directly here's
> the code:
>
> Logger logger = new Logger();
> logger.addListener(new SimpleLogListener(System.out));
>
> ISOChannel channel = new ASCIIChannel (
> "192.168.1.1", 10000, new ISOBAPackager());
>
> ISOMUX mux = new ISOMUX(channel);
>
> mux.setLogger (logger, "mux");
> new Thread (mux).start();
>
> ISOMsg m = new ISOMsg();
>
> m.set ( X, "XXXXXX");
> ........
>
> ISORequest r = new ISORequest(m);
> mux.queue(r);
> ISOMsg res = r.getResponse(15000);
ISOMsg res = mux.request(m,15000);
>
> if (res != null){
>
>
> System.out.println("MTI: " + res.getMTI().toString());
> System.out.println("RESPUESTA: " + res.getString(39));
> System.out.println("11: " + res.getString(11));
> System.out.println("41: " + res.getString(41));
> } else {
> System.out.println("timeout");
> }
>
> channel.disconnect();
Let the mux deal with the channel, this line is not needed?
>
> But here's the output when I run it:
You can get a lot more detail - which will help you see your flow from
including :-
((LogSource)channel).setLogger (logger, "channel");
Which will let the message flow from the channels perspective appear in
your log.
Assuming you leave your code building an ISORequest, also including:-
r.setLogger(logger, "isorequest");
will give detail from the ISORequest view.
What is providing the server functionality @ 192.168.1.1:10000? Does
this server have any logs, what it it doing with your request, what
response is it providing?
>
> <log realm="mux" at="Mon Feb 16 09:58:19 PYST 2009.663">
> <mux>
> <mux-stats connected="true">
> Connections: 1
> TX messages: 0
> TX expired: 0
> TX pending: 1
> RX messages: 0
> RX expired: 0
> RX pending: 0
> RX unmatched: 0
> RX forwarded: 0
> </mux-stats>
> </mux>
> </log>
The mux log detail above, states that a send (TX) is pending and
although connected nothing has (yet) happened through this mux. Are
there any other messages later in your log output?
> MTI: 0200
> RESPUESTA: null
> 11: 134396
> 41: IVR00001
>
> Why am I getting a 0200 in response? I know the request is going out
> but I don't know why I'm not getting a 0210 and why is not treating it
> as a null response.
I don't see how you are getting an 0200 back from
ISORequest.getResponse(15000) at all, but the extra logging and output
might help understand how.
How do you know it is 'going out', are you tracing your network? Do you
see anything 'coming in' from the sever?
Does the server at 192.168.1.1:10000 get the response, what does it then
do? Does it have any logs?
--
Mark
Horacio Estigarribia
getting a response
<log realm="mux" at="Mon Feb 16 11:10:43 PYST 2009.303">
<mux-stats connected="true">
Connections: 1
TX messages: 0
TX expired: 0
TX pending: 1
RX messages: 0
RX expired: 0
RX pending: 0
RX unmatched: 0
RX forwarded: 0
</mux-stats>
</mux>
</log>
2009.334">
<send>
<isomsg direction="outgoing">
<field id="0" value="0200"/>
<field id="2" value="XXXXXXXX"/>
</isomsg>
</send>
</log>
<log realm="channel/192.168.1.1:10000" at="Mon Feb 16 11:10:51 PYST
2009.880">
<receive>
<isomsg direction="incoming">
<field id="0" value="0200"/>
<field id="2" value="XXXXXXXX"/>
</isomsg>
</receive>
</log>
RESPUESTA: null
11: 134396
41: IVR00001
TX messages: 1
TX expired: 0
TX pending: 0
RX messages: 1
RX pending: 0
RX unmatched: 0
RX forwarded: 0
as if this is true. Also I printed mux.showCounters() after my
"response" and see there are no unmatched RX and TX Pending is 0 now.
Also if a run netcat locally I can see the ISO message going out from
my application.
The thing is that if I do a channel.receive() I get the right response
(0210) from the remote host, I'm trying to get the logs to see if it
is actually sending me a response.
Mark Salter
> I replaced the ISORequest with the mux.request, here's why I think I'm
> getting a response
>
> 2009.334">
> <send>
> <isomsg direction="outgoing">
> <field id="0" value="0200"/>
> <field id="2" value="XXXXXXXX"/>
> </isomsg>
> </send>
> </log>
> <log realm="channel/192.168.1.1:10000" at="Mon Feb 16 11:10:51 PYST
> 2009.880">
> <receive>
> <isomsg direction="incoming">
> <field id="0" value="0200"/>
> <field id="2" value="XXXXXXXX"/>
> </isomsg>
> </receive>
> </log>
setting 0210 as the mti, perhaps this the server indicating that your
request is bad in some way?
Are you really sending XXXXXXXX in field 2, or are you editing the
details before posting here?
If editing, perhaps just obliterate the card specific details (or use
test cards!) so we can the other fields present and what your messages -
in particular the response really contain.
If you *are* sending XXXXXXXX, perhaps the server doesn't like this
value as a card number?
> MTI: 0200
> RESPUESTA: null
> 11: 134396
> 41: IVR00001
> Connections: 1
> TX messages: 1
> TX expired: 0
> TX pending: 0
> RX messages: 1
> RX expired: 0
> RX pending: 0
> RX unmatched: 0
> RX forwarded: 0
>
> And if my test condition is if (res.isIncomint()) It still prints out
> as if this is true. Also I printed mux.showCounters() after my
> "response" and see there are no unmatched RX and TX Pending is 0 now.
> Also if a run netcat locally I can see the ISO message going out from
> my application.
>
> The thing is that if I do a channel.receive() I get the right response
> (0210) from the remote host, I'm trying to get the logs to see if it
> is actually sending me a response.
This feels unlikely, I don't want you to revert your code back to using
channels, but will instead suggest that perhaps other code changes have
affected the flow? Perhaps your server determines you are now sending a
bad or invalid request, where as previously you weren't?
Using a mux on top of a channel rather than a channel directly improves
your processing and you benefit from simplified code logic. It
certainly does not affect how the 'remote' server replies.
Have you modified any code within your local version of jPos source;
Anything changed in ISOMUX.java at all?
If you can add the loggers I have indicated previously and combine that
output with detail of what the server thinks of your recent requests;
let us have the detail here and I'm sure we can improve your result.
Are you (for example) incrementing your field 11 and regenerating your
field 37? Perhaps your server is treating these messages as duplicates
and thus errors?
This still does not explain why ISOMUX is passing back a 0200 'response'
to you though!
--
Mark
Horacio Estigarribia
Yes indeed, they were making some changes in their driver and didn't
let me know until this afternoon, that's why I kept getting the same
message back 0200 instead of 0210.
Now I get a response like I should.
I have a question regarding closing the connection, what is the
"right" way of ending the mux session, say.. if I get a timeout, I
tried channel.disconnect();
and mux.terminate(); but the application keeps running after the
exception:
<log realm="mux" at="Mon Feb 16 17:06:40 PYST 2009.650">
<muxreceiver>
<exception name="null">
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.jpos.iso.ISOMUX$Receiver.run(ISOMUX.java:334)
at java.lang.Thread.run(Thread.java:619)
</exception>
</muxreceiver>
</log>
I guess my question is what is your advice on terminating the thread
once I get a timeout.
Thanks
Mark Salter
> Yes indeed, they were making some changes in their driver and didn't
> let me know until this afternoon, that's why I kept getting the same
> message back 0200 instead of 0210.
test subject? Have you now established a rules around the advanced
reciprocal notification of change between you?
>
> Now I get a response like I should.
It still interests me how you were receiving the 0200 'response', but we
can save that for another time.
>
> I have a question regarding closing the connection, what is the
> "right" way of ending the mux session, say.. if I get a timeout, I
> tried channel.disconnect();
> and mux.terminate(); but the application keeps running after the
> exception:
>
> <log realm="mux" at="Mon Feb 16 17:06:40 PYST 2009.650">
> <muxreceiver>
> <exception name="null">
> java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:485)
> at org.jpos.iso.ISOMUX$Receiver.run(ISOMUX.java:334)
> at java.lang.Thread.run(Thread.java:619)
> </exception>
> </muxreceiver>
> </log>
>
> I guess my question is what is your advice on terminating the thread
> once I get a timeout.
Can you expand on your need please?
If you receive a null, indicating no response, you need to follow the
process dictated by the server owner balanced against the needs of your
acquiring device/network. This might involve a repeat message to the
server, or you generating a time-out response back to your acquirer.
The business processing rules of your position will dictate what is needed.
A time-out or lack of correctly formed response does not always mean the
network is at fault (as we have seen). You should implement the
time-out logic required and let the mux worry about a network level loss
of connection/reconnection; logging or alerting the appropriate
controllers of the 'problem'.
Do you need to terminate all connection with the remote server until you
next have a request to send in, at which time you will reconnect? If
so, is this approach how the server/system owner has mandated you do it?
If not, perhaps are you addressing the steps needed to cleanly shutdown
your system?
--
Mark
Alejandro Revilla
> Horacio Estigarribia wrote:
> > Yes indeed, they were making some changes in their driver and didn't
> > let me know until this afternoon, that's why I kept getting the same
> > message back 0200 instead of 0210.
> Not too unusual I'm afraid. Had you agreed to act as their guinea pig
> test subject? Have you now established a rules around the advanced
> reciprocal notification of change between you?
>
Followers of BOFH may like it.
>
> ...
> ...
>
> Do you need to terminate all connection with the remote server until you
> next have a request to send in, at which time you will reconnect? If
> so, is this approach how the server/system owner has mandated you do it?
>
If that's the case, he could use the OneShotChannelAdaptor. BTW, I
would recommend to use QMUX and a ChannelAdaptor, and Q2 instead of
ISOMUX and a Java based configuration.
Have a look at http://jpos.org/jposee/jPOS-EE.pdf and the client and
server simulators as examples.
Mark Salter
> Reminds me this old blog post: http://jpos.org/blog/2006/06/29/bcfh/
> Followers of BOFH may like it.
This lead me through to wikipedia and then:-
http://www.theregister.co.uk/odds/bofh/
and also into :-
http://pages.cs.wisc.edu/~ballard/bofh/bofhserver.pl
Which blessed me with an opening incantation of:-
"
The cause of the problem is:
Fluorescent lights are generating negative ions. If turning them off
doesn't work, take them out and put tin foil on the ends.
"
8)
--
Mark
PFY - I wish!