Achieve parallel bulk Incoming ISO messages processing in Request Listener.

[Charaka Wijesinghe]

Problem is Request listener is processing messages in sequential manner hence Acquire end is timeout when there is bulk of Incoming ISO messages, Please let me know my configuration issue here ,

mux

====

<?xml version="1.0" encoding="UTF-8"?>

-<mux name="bank-mux" logger="Q2" class="org.jpos.q2.iso.QMUX">

<in>bank-receive</in>

<out>bank-send</out>

<unhandled>bank-unhandled</unhandled>

<request-listener logger="Q2" class="IsoListener"> </request-listener>

</mux>

ChannelAdapter

=============

<channel-adaptor class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2"  name="bank-channel">

    <channel class="MyChannel" logger="Q2"

             packager="org.jpos.iso.packager.GenericPackager">

        <!--<property name="packager-config" value="D:/EFT/INWARD/PACKAGER/iso87ascii.xml" /> -->

<property name="packager-config" value="/EFT/INWARD/PACKAGER/iso87ascii.xml" />

        <property name="host" value="123.231.38.153"/>

        <property name="port" value="6342" />

       

    </channel>

    <in>bank-send</in>

    <out>bank-receive</out>

    <property name="timeout" value="300000" />

    <property name="keep-alive" value="true" />

    <reconnect-delay>10

MyChannel.java

=========

public class  MyChannel  extends RawChannel {

public  MyChannel  () throws ISOException {


this("xxx.xxx.xx.xxx", xxxx, new GenericPackager("/xx/xx/PACKAGER/iso87ascii.xml"), "IS0198730 ".getBytes());
}

public  MyChannel    (String host, int port, ISOPackager p, byte[] header) {
super(host, port, p, header);
}

public  MyChannel    (ISOPackager p, byte[] header) throws IOException {
super(p, header);
}

public  MyChannel    (ISOPackager p, byte[] header, ServerSocket serverSocket) throws IOException {
super(p, header, serverSocket);
}
}

IsoListner.JAVA

=============

public class IsoListener implements ISORequestListener {

ISOMsg resp210 = new ISOMsg();

@Override
public boolean process(ISOSource source, ISOMsg m) {

boolean result = false;
try {

//DB Operations

//COnstrut isoMsg Response 

source.send( isoMsg   );

return true

}catch(Exception e){

}

}

IN this implementation when we receiving the bulk of messages Acquire end is time out dut to exceeding time for response.

[Charaka Wijesinghe]

Need an advice from experts pls

--
--
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/6c4ea3ff-f532-4fec-bf98-511280de548dn%40googlegroups.com.

[Mark Salter]

You need to ask a smart question ( http://www.catb.org/~esr/faqs/smart-questions.html ) instead of chasing a reply for a bad one.

Include what evidence you see for your feeling that messages are being processed sequentially.

Are any response making it back to the requestor?

What matching is the requestor doing, from what you shared you look to be sending nothing back but a completely empty ISOMsg.

--
Mark


Sent from ProtonMail mobile



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

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CANZJJGcLhU%3DR5bEc02Qp8nnA3Ogm_b9KdbPkpyD2%2BD%3D3LR166w%40mail.gmail.com.

[Charaka Wijesinghe]

Mark,

1. Include what evidence you see for your feeling that messages are being processed sequentially. >> In the Q2 logs didn't see parallel 200 requests timestamp  being logged, because all the requests are server FIFO order based on the Q2 logs, ( for 200 incoming  ISO message always noticed subsequently, 210  outgoings ISOmessage only,  no 200 420 in middle of the 200 requests.  )

Observer Order only very sequential incoming messages in same milliseconds  

============

200 >

210>

800>

810>

Expected Parallel incoming request in the same millisecond to support to a parallelism 

=======

200> 

200>

800>

210

200

2.  Are any response making it back to the requestor? >> Yes based on the RequestListner receiving the order,  we are replying to Acquire party that coding I've removed from the RequestListner.

3.What matching is the requestor doing, from what you shared you look to be sending nothing back but a completely empty ISOMsg >> Actually, I've removed the coding and commented on what's happening in that code block. basically, what we doing there is matching 200/800/420 MTI and saving incoming request in our DB then we are constructing the response base on receiving MTI the replying to requestor reply process only take 1 second and , when there is bulk of ISO incoming message we noticed the delay in hitting process method in RequestListner

I understood the request listener triggering class for ISO server port as well as a bonded channel via channel adapter, in my case, we have a main switch and we've listened to external switch Port using channel adapter as I mentioned above MyChannel.java. So my confusion is how we can ask the request listener to accept the parallel request in this scenario, especially where I need to look at in my configurations that's the advice i need from you ,

Thanks.

[Mark S]

Before I try and work out what further advice to give, are you sure that your requestor wants and will send multiple requests in parallel - over multiple sessions and not wait for a response before sending the next request in?

How and where are you deploying your Server/QServer?

Have you already looked at section 2.3 of the Programmers guide to consider using org.jpos.iso.IncomingListener and then a TransactionManager to allow thread control and scaling ?

--

Mark

[Charaka Wijesinghe]

Mark,

are you sure that your requestor wants and will send multiple requests in parallel - over multiple sessions and not wait for a response before sending the next request in?

>> 1. let me explain one more time, our financial insutution is connect with national payment switch for receive fund transfer from other local financial institutions using channel and requestListner  

2. Requestor expecting response for related txns only eg- we receive the 200 iso mag then we should send 210 response thats all.

3.Real issue is when requestor is sending us Bulk of 200 MTai iso messages . We are only processing those txn in sequential manner which is leading to stackup txns in request listner. finally the delay time accumulating and starting to timesout requestor side due to delay in 210 iso response.(Hope you got the issue here)

4.Q2 server is started in main claww of this project as Q2 q = new Q2(deploy folder path).

No iso server  with xmls.

5. I’ve use thread pool to delegate task by starting thread inside the process method of requestListner.but didnt see a improvement. q2 log still indicate only sequentially txn serving.

You received this message because you are subscribed to a topic in the Google Groups "jPOS Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jpos-users/YzgNIiODAQw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/09788759-7567-482e-8cb0-42b78b8df07fn%40googlegroups.com.

[Mark S]

>>  No iso server  with xmls.

 I presumed proper ISO8583  messages not xml based.

Process the requests from the mux's unhandled space queue and deploy as many responders against that queue as you want parallelism - or go with my suggestion of the org.jpos.iso.IncomingListener and TransactionManager.

I just don't recall if via unhandled if the ISOMsg object will have the Source, so you will need to check that and use or derive it...

... but if you do use the other suggestion and a TransactionManager, then the Source is in the Context pushed out.

The problem is you are currently trying to respond in the mux's request-listener which is the wrong place to do so and you are therefore running in the single mux thread.

--

Mark

[Charaka Wijesinghe]

++ Team

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/a955f3b5-0004-4b8a-a5db-250db8b7ddd9n%40googlegroups.com.

[murtuza chhil]

Never block the ISORequestListener.

If you do need to block, have your process method spawn threads.

Use transaction manager, as soon as you get a request, hand it off to the transaction manager by placing a newly created Context object with the ISOMsg and source. The transaction manager has sessions (threads) for processing in parallel. The transaction manager does the processing via Participants and when you want to send the response, use the source in the context to send the response back.

From http://jpos.org/doc/proguide-draft.pdf

" ISOServer uses a ThreadPool in order to be able to accept multiple connections at the same time. Every socket connection is handled by a single thread. If your request listener implementation takes too long to reply, new messages arriving over that session will have to wait for their response. To solve this problem, your ISORequestListener implementation should run in its own thread pool so that its process(…) method will just queue requests to be processed by a peer thread."

-chhil

[Charaka Wijesinghe]

Yes , i've implemented txn mngr with participant. didnt touch the request listner.now seems good.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/7e0fff25-9b7c-4398-ab2e-e790f4c7341bn%40googlegroups.com.