ignore-iso-exceptions

[nag]

Hi,

I have a typical situation where I receive a string (TIMEOUT_ERROR) in my ISO client instead of an ISO message as a response.

I am using my custom channel by extending BaseChannel and overriding the getMessageLength() method.

As expected I get NumberFormatException as I receive a string in response and converted to ISOException. first 4 bytes 'TIME' can't be converted into int.

I'm facing the following challenges

1. When I receive the error string response is not matched with the request (my key fields are 11,37)
2. by default ChannelAdaptor disconnects upon ISOException
3. It connects after re-connect interval of 10 sec.
4. The requests which are submitted already get timedout

I have found a property(ignore-iso-exceptions) which i can set on channel adaptor after going through the API, but this is not honored, I am using jpos 1.6.4

Let me know the best way of handling the situation

Thanks in advance

Regards
Naga




   

[Mark Salter]

On 15/11/2012 19:22, nag wrote:
> Hi,
>
> I have a typical situation where I receive a string (TIMEOUT_ERROR) in
> my ISO client instead of an ISO message as a response.

The interface you are connecting to returns a string instead of a
properly constructed ISO message?

Can you ask them not to?

>
> I have found a property(ignore-iso-exceptions) which i can set on
> channel adaptor after going through the API, but this is not honored, I
> am using jpos 1.6.4

Grab and use the latest version, you really are missing out on a lot of
fixes and features?


--
Mark

[Naga Babu]

Hi Mark,

Thanks for your quick reply.

I have requested but they have denied. Obviously 'Server' can reject 'Client' requests.

More obvious answer is 'there are other clients who have handled and why don't you'.

I will try to use the latest version, but can you shed light on handling non-ISO message.

If I am able to ignore this message my problem is solved for now.

Thanks
Naga

--
--
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  "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

[Mark Salter]

On 16/11/2012 21:16, Naga Babu wrote:
> More obvious answer is 'there are other clients who have handled and why
> don't you'.

:-)

>
> I will try to use the latest version, but can you shed light on handling
> non-ISO message.

You certainly need to spot it and throw away their rubbish response
asap, you need to identify how to spot the bad rubbish as early as
possible and certainly not processes it.

It there anything in the message - like the bad length - that is always
the same?

Can you explain how the timeout error occurs - what drives it? I'm
wondering if it is something bad you are doing to them, or if they have
a down stream interface this is not responding (against requests you are
sending to them and they are passing on)

Can you share which software/system is generating this message to you -
just interested, so if you can't no worries.


--
Mark

[Chhil]

Is this timeout string response part of the specification?
Do you need to react to this and do something like reverse the previous request?

You could handle it your channel, peek for this string and handle appropriately. So instead of getting the number of bytes the indicate length, get number of bytes of your timeout string and take appropriate action.


-chhil

[Naga Babu]

Hi Mark,

My ISO requests are well constructed and fine.

Yes, you guessed it right. They have a core downstream interface which throws this error and their ISO interface just passing this to me. Ideally they should have wrapped this as a properly constructed ISO before responding to clients.

When this happens they always send the same string 'TIMEOUT_ERROR'. Will share you the system details personally

Chhil:

I need to reverse the previous request as this is a timeout. Is this possible ? As this is not an ISO message and can't see key fields like 11 and 37 in my case, how can the library match corresponding requests?

So this particular request waits for timeout interval(15 sec), and then get Reversed as it can't see corresponding response.

Channel disconnects and connects again on ISOException. So, I got to reduce the re-connect delay to 2 sec so that other requests will be processed with a slight delay.
   
I would like to handle this in my channel, what is the best way?  do you want me to raise a special exception in getMessageLength() and handle it in receive()?

Thanks
Naga

--
Mark

[chhil]

Regarding reversals:
You are probably sending a message received to an upstream entity for authorization.
Now when you receive a timeout does that mean gte message was not approved?

If it is guaranteed to be declined then you could create a declined response back to where the request came from.
If it's not guaranteed then
The interface that you received the request from will timeout on not receiving the response and would initiate a reversal. You may not need to initiate the reversal on your own.

Reversing a message yourself may not be possible as you may have sent the upstream entity multiple requests and you won't be able to match it to the correct one.

Handling Timeout in channel:
This is a suggestion. Instead of reading just enough bytes for length determine if it's a timeout string and discard it.

-chhil

[Chhil]

Forgot to add, if you discard the timeout, the place where you sent the request using the mux will timeout and you can take appropriate action there, as you will have the request with you.

-chhil

[Naga Babu]

The default behavior is fine as it reverses after timeout.

I want to know how to discard the message.

-- Naga

[Chhil]

Your channel is reading in bytes to get the length. If can be made smarter to peek for the error by reading in more bytes and return a length of 0 if the string is found?

So if its a 2 byte  length header and its TI then read in 11 more bytes and if it forms the TIMEOUT_ERROR string return a length of 0

Else return a length of of number formed with bytes minus 11 to get the rest of the message.

Just to make sure that a ISO message with length TI is not ignored :)

Haven't tried this myself but it looks feasible.

-chhil

[Naga Babu]

Returning the length of 0 will solve the problem?

Let me try this I will post you the result

-- Naga

[chhil]

But make sure to read all those bytes.

[Naga Babu]

I am reading full bytes, and returning length 0 but BaseChannel throws ISOException. I have checked the source and it is ended in last else block as shown below. So, this is not true discard of the error string as my channel disconnects and connects again on this ISOException. Please suggest

if (len == -1) { -----------

else if (len > 0 && len <= getMaxPacketLength()) { ----------

 else
                    throw new ISOException( -----------

[Naga Babu]

output:

<log realm="org.jpos.q2.iso.ChannelAdaptor" at="Sat Nov 17 10:15:30 EAT 2012.857">
  <warn>
    channel-receiver-1-receive
    <iso-exception>
      receive length 0 seems strange - maxPacketLength = 100000
      org.jpos.iso.ISOException: receive length 0 seems strange - maxPacketLength = 100000
    at org.jpos.iso.BaseChannel.receive(BaseChannel.java:614)
    at org.jpos.q2.iso.ChannelAdaptor$Receiver.run(ChannelAdaptor.java:305)
    at java.lang.Thread.run(Thread.java:662)
    </iso-exception>
  </warn>
</log>

[chillum]

In your channel adaptor try adding a property ignore-iso-exceptions having value yes.

From ChannelAdaptor code

ignoreISOExceptions = "yes".equalsIgnoreCase (persist.getChildTextTrim ("ignore-iso-exceptions"));

...............

if (!ignoreISOExceptions) {
                        disconnect ();
                    }


So diconnects shouldn't happen.

-chhil

[Naga Babu]

I have set this property and tried both values 'true' and 'yes'. In fact if you see my first post this is exactly what I have done. my problem is this is not honored. wondered why and posted to jpos users. I have even set the class variable  to true. I have gone one step further and hardcoded just before the condition. still disonnect() happens. wondering why !!!

                    ignoreISOExceptions = true; // hardcoded
                    if (!ignoreISOExceptions) {
                        disconnect ();
                    }

-- Naga

[Naga Babu]

I have done this on Receiver run() method. not on Sender

                        ignoreISOExceptions=true; // hard coded
                        if (!ignoreISOExceptions) {
                            sp.out (reconnect, new Object(), delay);
                            disconnect ();
                            sp.out (in, new Object()); // wake-up Sender
                        }

-- Naga

[Mark Salter]

On 17/11/2012 05:57, Naga Babu wrote:
> My ISO requests are well constructed and fine.

Good.

>
> Yes, you guessed it right. They have a core downstream interface which
> throws this error and their ISO interface just passing this to me.
> Ideally they should have wrapped this as a properly constructed ISO
> before responding to clients.

Indeed, anything else just seems lazy :-).

>
> When this happens they always send the same string 'TIMEOUT_ERROR'. Will
> share you the system details personally

And they will always send that - guaranteed? Can they reply with any
other Strings?

> I need to reverse the previous request as this is a timeout. Is this
> possible ? As this is not an ISO message and can't see key fields like
> 11 and 37 in my case, how can the library match corresponding requests?

As I think you have agreed in the rest of this thread, the waiting
requester/MUX will time-out and can generate the reversal, there is no
way that the message above gives any indication of the request that
failed (which is why it is a poor approach); but then it doesn't need too.

>
> So this particular request waits for timeout interval(15 sec), and then
> get Reversed as it can't see corresponding response.
>
> Channel disconnects and connects again on ISOException. So, I got to
> reduce the re-connect delay to 2 sec so that other requests will be
> processed with a slight delay.

What you need to do is to stop the Exception happening and protect your
connection from their shortfall.

>
> I would like to handle this in my channel, what is the best way? do you
> want me to raise a special exception in getMessageLength() and handle it
> in receive()?

In your getMessageLength, you can carefully check if this message (or
any others?) arrive. If they do, return the known/calculated length of
the remaining rubbish *only* (you don't want to absorb too many bytes
later as they may form the beginning of the next message/response) and
then return the length of the rubbish. *Then* in your Channel's
getMessage method you can check the byte array and if a rubbish reply
you can conditionally build a real ISOMessge to return so that your
current processing can safely treat it as a properly formed, but
unsolicited/expected message, log it and keep going - they key here is
we are avoiding throwing an Exception.


--
Mark

[Mark Salter]

On 17/11/2012 10:22, Naga Babu wrote:
> I have gone one step further and
> hardcoded just before the condition. still disonnect() happens.
> wondering why !!!

Are you certain you are compiling and running this new version :-) ?

But I think not to worry about handling the Exception, please see my
other response, I hope it will save you some grief.


--
Mark

[chhil]

Can you post the channel adaptor config here?

[Naga Babu]

Hi,

ChannelAdaptor configuration is pasted at the end. I am using jpos1.6.4 , that could be the reason why the configuration is not picked. I think this property would be fine in latest version. I will confirm.

Good news is when I hard code  ignoreIsoExceptions=true, with 1.6.4 channel is not disconnecting. I am testing with simulator locally for now. I will test this with actual server and update you.

I should also make sure that Server will not disconnect the client channel when it throws timeout error string. otherwise I would end up writing my subsequent requests to closed channel and never try to re-connect as configuration says ignoreISOException=true. Then I will end-up praying for network disconnection so as to re-connect ;-) 

next steps

1. use 1.6.4, hard code ignore-iso-exceptions=true and test with actual Server
2. Pull the latest version of jPos, make sure configuration works and test with actual server

I will post you my findings. Thank you for your patience

<?xml version="1.0" ?>
<channel-adaptor name='1-adaptor' class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
 <channel class="MyChannel" logger="1" realm="1-channel"
     packager="MyPackager">
  <property name="host" value="127.0.0.1" />
  <property name="port" value="5002" />
   <property name="keep-alive" value="true" />
   <property name="keep-alive" value="true" />
   <property name="ignore-iso-exceptions" value="yes"/> <!-- Tried value="true"  -->
 </channel>
 <in>1-send</in>
 <out>1-receive</out>
 <reconnect-delay>10000</reconnect-delay>
 
</channel-adaptor>


-- Naga

[Mark Salter]

On 17/11/2012 11:35, Naga Babu wrote:
> I should also make sure that Server will not disconnect the client
> channel when it throws timeout error string. otherwise I would end up
> writing my subsequent requests to closed channel and never try to
> re-connect as configuration says ignoreISOException=true. Then I will
> end-up praying for network disconnection so as to re-connect ;-)

You should be using a MUX and not writing to the Channel directly, but
perhaps you are and I read this wrong.

I think you can avoid Exceptions and the need to disconnect at all,
please see my other responses.

:-)

--
Mark

[Naga Babu]

Mark,

Agreed. Decorating the error with dummy ISOMsg is a better approach rather than ignoring the ISOExceptions as it effects all communication between client and server. I hope this goes to un-handled queue safely.

Let me try overriding the getMessage() method


-- Naga

--
Mark

[chhil]

The configuration is incorrect. It needs to be an element having gte value yes.

[Mark Salter]

On 17/11/2012 11:58, Naga Babu wrote:
> Let me try overriding the getMessage() method

and getMessageLength :-)

--
Mark

[chillum]

I probably misguided you. If you are going to use the
ignore-iso-exceptions with a value of yes it needs to be an xml
element...see snippet below.
Just stepped through code and it pick up the value.
[Dont use the property value way of doing it].

<channel-adaptor name='XXX'
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
<channel ....
....
</channel>
<ignore-iso-exceptions>yes</ignore-iso-exceptions>
<in>Asend</in>
<out>Areceive</out>
<reconnect-delay>10000</reconnect-delay>
</channel-adaptor>

Sorry Mark, for will not interfere with your suggestions...its a
Saturday, I am off :)

-chhil

[Naga Babu]

Thanks Chhil for correcting. I have made changes as below

Mark: I have done the below as suggested and working fine with my server simulator. I am yet to test this with actual server. will post you

 in getMessageLength() : I made sure the remaining bytes are read fully and returning '0' length.

catch (NumberFormatException e) {
                    String s= new String(b);
                    if(s.equals("TIME")){
                        byte[] b1 = new byte[9];                       
                        // read other bytes
                        serverIn.readFully(b1,0,9);
                        System.out.println("Remaining String"+new String(b1)+".");
                        return 0;
                    }

getMessage() method:
 
               int len  = getMessageLength();
               if(len == 0){
                    ISOMsg msg =  getCustomMessage();
                    evt.addMessage (msg); // logging purpose
                    //cnt[RX]++; // do we need to count?
                    return msg;
                }

getCustomMessage() method:

private ISOMsg getCustomMessage() throws ISOException{
                   
                // Return dummy ISO
                ISOMsg echoISO = new ISOMsg();
                echoISO.setDirection(ISOMsg.INCOMING);
                echoISO.setMTI("0810");  // consider this as echo response
                echoISO.set(11,"MI0001");               
                echoISO.set(48,"TIMEOUT_ERROR");
                echoISO.set(70,"301");

                return echoISO;
    }

-- Naga

--

--
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  "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

[Naga Babu]

Hi Mark,

Thanks for the right solution. This is working fine. I will mark this as complete

Regards
Naga

[Mark Salter]

On 26/11/2012 18:39, Naga Babu wrote:
> Thanks for the right solution. This is working fine. I will mark this as
> complete

Great, thanks for reporting back.


--
Mark