SpaceInterceptor with unregisterExpirable() event

[QSwitch]

Hi jPOS experts,

I understand that with SpaceInterceptor we can "intercept" some of queue operation, such as "out", "in", "put", "push", etc.

However, in my case, I also need to be notified when an etnry in the queue become expired.

I can see that in TSpace implementation, there is a call to unregisterExpirable when an entry become expired.

But, because unregisterExpirable() is a private function member, I cannot simply extend TSpace and override it.

Please advice, what is the correct way to catch this expired event ?

Thanks in advance for your advice.

[Alejandro Revilla]

We don't have support for expirable listeners, specially since the Space garbage collector call has to be very fast, but if you tell us your use case for this, we may be able to tell you how we solved similar situations.

If you use the TransactionManager, and you want to know which transactions (contexts) didn't actually reach the TM, there's an easiest, fast, understandable, and reliable way to do this. You do not use expiration, instead, you let the first participant (i.e. the 'PrepareContext' participant) check the Context's TIMESTAMP, and if it should have expired already, you discard the entry.

In jPOS 3 ('next' branch), we have support for timeouts like that at the TM level (see https://jpos.org/blog/2022/05/TM-timeout-and-max-timeout/).

--

@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
---
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/7d7d800f-df28-4368-b85a-c4f3ce27431an%40googlegroups.com.

[QSwitch]

Hi Alejandro,

Thank you for your quick response and advice.

Exactly, my goal is to discard expired Context and notify the requestor with "timeout" or "host not available" kind of response.

Your advice looks promising and elegant solution to my situation, I'll give it a try.

Regards.

[Alejandro Revilla]

At some point, I've used a complex strategy where I would setup a timer at the Context level (from the request listener) and then use that timer to get ahold of the context.

But that's overkill, and heavy for the TimerTask. Picking these entries on the first participant, and expiring them, is easier.

--

@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
---
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/6af835b2-3e1a-478f-8a1e-ad0147f955den%40googlegroups.com.

[QSwitch]

Hi Alejandro, as suggested, I come up with following solution, please let me know your view on this, so far it works as my expectation.

[Listenet] -> [Transaction Manager] -> [Host]

At Listener, we use Jetty Async Servlet Handler, and use its startAsyc as single place to managed the timeout for each incoming request. Servlet timeout event will flag a variable within the Context. Context sent to Transaction Manager without any timeout.

Then my Transaction Manager looks like this:

<participant class="selector.prepareTransaction" logger="Q2">
    <property name="timeout" value="exit" />
    <property name="default" value="start" />    
</participant>

<group name="start">
    <participant class="participant.A" logger="Q2"></participant>
    <participant class="participant.B" logger="Q2"></participant>
</group>

<group name="A">
</group>

<group name="B">
</group>

<group name="exit">
</group>

[Alejandro Revilla]

Perfect. You can consider using the lightweight QRest (see http://jpos.org/doc/jPOS-EE.pdf) as an alternative to Jetty. QRest is based on Netty and it's pretty fast. It's handling one of the largest merchant chains with a large number of branches in the US with a massive load without any problem, and it was designed exactly for that, a fast HTTP->TransactionManager thin layer.

--

@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
---
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/19f03a76-1b27-4e98-bfe3-d51cb9199834n%40googlegroups.com.

[QSwitch]

Hi Alejandro,

Thanks for the suggestion to use QRest, let me take a look into it.