Clearing Q2 Internal queue when Source System closes and re-opens connection

[shadei...@gmail.com]

Good day,

I have had users ask me this question overtime and would like to get some idea about it.

When the Postilion FEP application resyncs an interchange, it closes and reopens connections to the Q2 application before sending requests again. What we've noticed is that if the Q2 application service is not restarted as well it continues to process the old request and then the queue on FEP increases.

Is there a way of clearing the internal queue in Q2 without restarting the service if the source closes connection? What would be the best recovery process for this without impacting the system drastically?

Regards,

Yetunde

[chhil]

https://jpos.org/blog/2014/04/you-want-a-timeout/

If Postilion has sent requests, and they are in the jpos' queue, they are in-flight. Now your Postilion side disconnects and reconnects. The disconnect should have no impact 

on jpos as those transactions still need to be processed, it may not see Postilion when it's disconnected and be unable to send the response. 

Those requests still have a financial impact (those in-flight ones may have authorized/reversed/advised trans). 

You want the in-flight transactions in jpos to stop processing when Postilion disconnects (even if Postilion does not disconnect and there is a TCP issue it can still disconnect). 

Which from a financial transaction flow does not make sense to me.

What you are trying to do is, I made some changes to the Postilion config and by resynching will apply those changes, but I also want to prevent the transactions I already sent from being processed by Q2.

If your Postilion queue is increasing, you can investigate the reasons why it's increasing, is it a Postilion problem or a jpos problem. 

Is jpos configured correctly (sessions) and all its participants are returning in time or if some of your participants are blocking causing the Postilion queue to increase.

The jpos system monitor should be looked at , it logs useful information at regular intervals, it has information on participants that have taken long and blocking.

-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
---
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/9bc26528-3fda-4a88-9dd1-57df352a8466n%40googlegroups.com.

[shadei...@gmail.com]

Hello Chhil,

Thanks for your response. I'm indeed looking at the logs and system monitor to notice when any participant gives an issue and fixing as required. Or informing them when it's something they need to fix.

But the Postilion team feel that we should stop processing all transactions once they resync or there's a break in connection. This is because the JPOS application keeps processing the old transactions that the FEP is not expecting any response to and new transactions end up at the end of the queue. I will think through this a bit more and have a chat with them.

Regards,

Yetunde

[Mark Salter]

This Postillion position (if that really was their guidance) is disruptive on both sides of their system and in my opinion is very  poor.

As it stands, they appear happy to let the choice to rotate their system disrupt all in-flight transactions, letting everyone else sort it out.

Of course you need to handle unintentional outages as best you can, but still.

Currently your responses are not being sent back on the connection that has been stopped, so determine that condition and perhaps instead of an Exception, catch and discard the response you can't deliver (and they don't now want?).
I presume the acquirer will generate time out (cardholder pain as they wait and then  or swap cards!!) reversals on not receiving the response to balance the books.

For me, and ideally, the act of Postilion being recycled (are these for maintenence of some sort ?) would start a new connection but also allow the old to breifly drain so that no in-flight transactions are bothered; once drained close the connection and clean up.
This of course requires coordination within Postillion to separate the old from the new setup (i am assuming change generated) and honour the same processing out to the acquiring system or devices.

Just my 2 cents, defiantely sort out why the responses end up sitting at the end of your 'queue' and dispose of them cleanly.; taking care of the balances if there is no assured revera
reversal processing dictated.

--
Mark

-- 
Mark

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/eb457c1d-acfa-4c93-85e0-8c6f55dee240n%40googlegroups.com.