Storage %SYSTEM.Event
Hello, How are you doing?
I'm currently developing a proyect in wich I want to use %SYSTEM.Event to process queues. I realized that if a queue has events pending to be sent to the listeners, when I restart the cube the queue with all its events are deleted.
Is there a way to store the queue with their messages in a Global?
I've checked the documentation but I can't find any option for this prupose.
https://docs.intersystems.com/supplychainlatest/csp/documatic/%25CSP.Doc...
Thank you!
Product version: Caché 2018.1
$ZV: Cache for Windows (x86-64) 2018.1.4 (Build 505_1) Thu May 28 2020 10:12:49 EDT
%SYSTEM.Event is only for Inter-Process communication and messages sent through SharedMemory, which may cause some issues if not used correctly (overflow for instance).
The only way to send it to Global, is to make the listener which will do it, but using %system.Event in this case makes no sense, if you could do it without it.
Thanks Dimitry,
In which scenario could I be affected by the overflow. Sending messages without a listener who read them, for example?
Is there a way to know how many messages are in a queue, to avoid this problem?
Thanks again
Yes, if you send too much, and the listener will not be able to read such fast, it may cause overflow, and the whole server may stop working. You can use Count(resourceName)
My my, I had looked for the Count command but had not found it. Sorry for the silly question.
Thanks Dimitry!
You should use $System.Event to wake-up queue handlers, not as a queue itself.
I don't have details of your project but when you say "I want to use %SYSTEM.Event to process queues" and ask "Is there a way to store the queue with their messages in a Global?" I think that what you describe is exactly what an IRIS interoperability production does.
In fact, an IRIS interoperability production internally use %SYSTEM.Event to process queues and messages are indeed queued and persisted (in globals).
Within an IRIS interoperability production queued messages are preserved across system restart (and crash!), in addition messages are traced, can be resent etc etc.
So my question is, given your requirements, why not using an interoperability production instead of reinventing (or reimplementing) the wheel?
Enrico
Hello Enrico,
The reason for doing it in this way is because we haven't yet migrate to IRIS. We're working with the 2018 version currently.
Thanks for your answer 👍
I didn't realized you are still using Caché 2018! 😮
Add this to the, possibly long, list of good reasons to migrate to IRIS! 😉😊
Enrico
Hi Daniel,
Maybe you can download the IRIS Community version, and use the code of Ens.Job and Ens.Queue classes how a reference, and implement your own version of queue processing with $System.Event.
💡 This question is considered a Key Question. More details here.