I mean, is onMessage method would be triggered exactly once per atomic message from server, or:
Whether the message is short, 2 or more message might only trigger onMessage only once with one concatenated message, so we have to split the message manually?
Whether the message is long there would be multiple onMessage triggered with partial message each one so we have to concat the message manually?
I'm using C# and javascript for client side (2 product) and golang for server side
All the messages are events technically, you can only read the data from them. You can also control buffer size for both write and read operations, but I think that if the message reaches those limits it wouldn't be separated
Related
The Event Queue is a box that get messages and handles them.
Could you please say , where are the messages that PostMessage and SendMessage are stored? and how to tell who send what message?
What variables can be inspected to get the information?
Where are the messages stored?
They are stored in an internal data structure associated with a thread. Note that each thread has zero or one message queues. A message queue is not created automatically for a thread, but created on demand when the thread calls a function that requires a message queue.
Note also that sent messages, those delivered by SendMessage do not appear in the queue. Sent messages are synchronous and so not queued.
How to tell who send what message?
In general that is not possible: Can I determine which process sent my window a message?
What variables can be inspected to get the information?
You cannot. You can use PeekMessage to find out whether or not the queue contains a specific message, or find the first message in a given range. But there is no functionality to dump the entire message queue.
I'm new to JMS and HornetQ.
I'm wondering if there is a way to implement Message Translator Pattern using HornetQ to split data from a message in a set of smaller data and send them. I explored Bridge and Divert solutions but I can't get how to do it using org.hornetq.core.server.cluster.Transformer and org.hornetq.core.server.ServerMessage. Where can I find some docs about it? Am I looking in the right direction?
In short no(I've no Idea on camel). You cannot modify the jms body once sent until its consumed by a client(body is immutable). However you can change message headers and message properties. The org.hornetq.core.server.cluster.Transformer interface is used for modifying the headers/properties. Hence you are left with two options.
Consume the message, chunk the message based on your algorithem and send to other queues or put back to the queue(but be careful to avoid loop, by having suitable selector).
Other approach is chunk the message then send with message property to differentiate the message. And use the diverter with filter based on the message property(you can use exclusive/non exclusive strategy to send only/send copy of message to the other queue.)
I am writing a Message Handler for an ebXML message passing application. The message follow the Request-Response Pattern. The process is straightforward: The Sender sends a message, the Receiver receives the message and sends back a response. So far so good.
On receipt of a message, the Receiver has a set Time To Respond (TTR) to the message. This could be anywhere from seconds to hours/days.
My question is this: How should the Sender deal with the TTR? I need this to be an async process, as the TTR could be quite long (several days). How can I somehow count down the timer, but not tie up system resources for large periods of time. There could be large volumes of messages.
My initial idea is to have a "Waiting" Collection, to which the message Id is added, along with its TTR expiry time. I would then poll the collection on a regular basis. When the timer expires, the message Id would be moved to an "Expired" Collection and the message transaction would be terminated.
When the Sender receives a response, it can check the "Waiting" collection for its matching sent message, and confirm the response was received in time. The message would then be removed from the collection for the next stage of processing.
Does this sound like a robust solution. I am sure this is a solved problem, but there is precious little information about this type of algorithm. I plan to implement it in C#, but the implementation language is kind of irrelevant at this stage I think.
Thanks for your input
Depending on number of clients you can use persistent JMS queues. One queue per client ID. The message will stay in the queue until a client connects to it to retrieve it.
I'm not understanding the purpose of the TTR. Is it more of a client side measure to mean that if the response cannot be returned within certain time then just don't bother sending it? Or is it to be used on the server to schedule the work and do what's required now and push the requests with later response time to be done later?
It's a broad question...
I have a very simple flow, a JMS Message starts a process which receives a List of objects. A foreach iterates through this list and sends a JMS Message to component to process the object in the list. This component needs to send a completion notification back to the flow process so it can carry on. Does anyone have any idea of how this can be acheived?
Thanks.
How do you implement sending this message? Using a custom work item node? I see two options:
if you are always expecting a result JMS message, you could have your work item handler send the JMS message when the work item node is triggered but only complete the work item when the expected result message has arrived, this will make the flow only continue if the result message has been received (and you can for example send the work item id as some kind of context parameter in your message so you know which work item to complete if the result comes back)
if you also want to handle more unexpected JMS messages (not necessarily the result of a first request JMS message), you can use an event node for that, and have a JMS listener that translates incoming JMS messages (of a specific type) to signalEvent(..) invocations, that will then continue the flow from the event node forward.
Kris
I have a single AMQ queue that receives simple messages with string body. Consider I'm sending CLSIDs as message bodies. CLSIDs could be not unique, but I'd like to reject all messages with not unique bodies and keep only single instance of such messages in the queue. Is there any simple way to do it?
Currently I'm using a workaround. Messages from the queue are consumed by some processor that tries to insert bodies into a simple DB table with UNIQUE constraint applied to message_body field. If processor inserts the messages succesfuly - it's assigned to exchange.out.body and sent to other queue. If ConstraintViolationException is thrown - nothing is resent to other queue.
I would like to know does AMQ support something similar out of the box?
I believe you can write an interceptor for activemq where you can perform certain actions on messages. Check out: http://activemq.apache.org/interceptors.html
That being said, in my personal opinion this is bad practice. ActiveMQ is a messaging system which should only be responssible for transport of the message. All logic can beter be performed using your application ( either make sure the sender cannot send the same message more then once OR , create an intermediate consumer which indeed matches the received body with a database that contains already seen message bodies BEFORE, routing the message to the actual receiver queue)