I already posted a question here, and I finally found the source of the problem myself. But the issue remains unresolved.
Arriving messages are stored in a queue until a matching activity is found. But if the activities are not activated in the same order as the messages arrived, the process will block.
I modelled a diagram which is available here, the corresponding BPEL package can be downloaded from here.
The first process remains blocked on Receive2 whereas the second completes.
I'm testing on the BPS version 2.1.2
When multiple processes are communicating with each other, I do not always know if a message will arrive before or after another one. I think this should be possible, I see no reason why not: the messages are present in the H2 database, so a suitable query sould be able to return them.
Thanks in advance for your help.
Related
After I sent a message to my GCP subscription, it takes a minute or two (should be instant) to appear in my Nifi flow. At this point, I see a bunch of XML and my payload isn't there. Does anyone know what's possibly happening?
If your push messages are not acknowledged then it may slow down delivery of the rest significantly.
Your use case looks more like the endpoints don't acknowledge it's delivery instantly (or acknowledgement is late due to some other reasons). If the message is not acknowledged immediately then a system will retry to deliveer it (with some delay) and it will keep trying untill it's acknowledged.
Also look at the Message Flow Control documentation which albo may point you to a solution.
Similar topic was also discussed here in StackOverflow (which might help you).
I am looking into ways to order list of messages from google cloud pub/sub. The documentation says:
Have a way to determine from all messages it has currently received whether or not there are messages it has not yet received that it needs to process first.
...is possible by using Cloud Monitoring to keep track of the pubsub.googleapis.com/subscription/oldest_unacked_message_age metric. A subscriber would temporarily put all messages in some persistent storage and ack the messages. It would periodically check the oldest unacked message age and check against the publish timestamps of the messages in storage. All messages published before the oldest unacked message are guaranteed to have been received, so those messages can be removed from persistent storage and processed in order.
I tested it locally and this approach seems to be working fine.
I have one gripe with it however, and this is not something easily testable by myself.
This solution relies on server-side assigned (by google) publish_time attribute. How does Google avoid the issues of skewed clocks?
If my producer publishes messages A and then immediately B, how can I be sure that A.publish_time < B.publish_time is true? Especially considering that the same documentation page mentions internal load-balancers in the architecture of the solution. Is Google Pub/Sub using atomic clocks to synchronize time on the very first machines which see messages and enrich those messages with the current time?
There is an implicit assumption in the recommended solution that the clocks on all the servers are synchronized. But the documentation never explains if that is true or how it is achieved so I feel a bit uneasy about the solution. Does it work under very high load?
Notice I am only interested in relative order of confirmed messages published after each other. If two messages are published simultaneously, I don't care about the order of them between each other. It can be A, B or B, A. I only want to make sure that if B is published after A is published, then I can sort them in that order on retrieval.
Is the aforementioned solution only "best-effort" or are there actual guarantees about this behavior?
There are two sides to ordered message delivery: establishing an order of messages on the publish side and having an established order of processing messages on the subscribe side. The document to which you refer is mostly concerned with the latter, particularly when it comes to using oldest_unacked_message_age. When using this method, one can know that if message A has a publish timestamp that is less than the publish timestamp for message B, then a subscriber will always process message A before processing message B. Essentially, once the order is established (via publish timestamps), it will be consistent. This works if it is okay for the Cloud Pub/Sub service itself to establish the ordering of messages.
Publish timestamps are not synchronized across servers and so if it is necessary for the order to be established by the publishers, it will be necessary for the publishers to provide a timestamp (or sequence number) as an attribute that is used for ordering in the subscriber (and synchronized across publishers). The subscriber would sort message by this user-provided timestamp instead of by the publish timestamp. The oldest_unacked_message_age will no longer be exact because it is tied to the publish timestamp. One could be more conservative and only consider messages ordered that are older than oldest_unacked_message_age minus some delta to account for this discrepancy.
Google Cloud Pub-sub does not guarantee order of events receive to consumers as they were produced. Reason behind that is Google Cloud Pub-sub also running on a cluster of nodes. The possibility is there an event B can reach the consumer before event A. To Ensure ordering you have to make changes on both producer and consumer to identify the order of events. Here is section from docs.
Qpid offers responses to the received message. For parallel processing purposes we have multiple instances of the application that are listening to the same queue. The problem is that I would like that exactly the same instance receives the response. I believe that this can be done using correlation ids, but I cannot find an example how to do that with Qpid.
I searched the web and found discussion from 2009 (http://qpid.2158936.n2.nabble.com/get-message-by-correlationId-td3440876.html) where they aimed to add selectors shortly. This is probably the associated ticket (https://issues.apache.org/jira/browse/QPID-4558). There is finished subtask "Initial selector implementation", so I belive that this is implemented.
I was searching the API documentation and found methods getCorrelationId() and setCorrelationId(), but I cannot find an example how to filter the messages from queue.
Thanks.
I am trying to solve the problem of generating distributed timing events for my application on the amazon cloud:
A server gets a message. As a result the system has to do something within X minutes. My problem is that the system needs to potentially handle millions of messages per second during peak time. Also, during that time interval the server that got the message might crash. So I am looking for a distributed solution that can receive a message, and then fire another message with a guarantee several minutes later.
I could design a sharded system by myself, but I was hoping that some distributed streaming framework can do this easily. But what I found so far are ones that complete transactions immediately.
Your question is somewhat vague, but if you are looking for a fault-tolerant, geographically distributed way of processing messages, the you should take a look at AWS SQS or SQS in combination with SNS.
http://aws.amazon.com/sqs/
http://aws.amazon.com/sns/
I have simple bpl process with 3 invokes in loop. One of instances hang without any visible reason. So process is in active state but it is not executing any longer. Last logged activity is call to invoke. I search database and find out that both request and response are present in table ode_message and they looks correctly. But output variable from invoke in table ode_xml_data is not filled. There is no logs in bps from time when message arrived. Is any way to find out what happen wrong?
I'm try to use Wso2 BPS 2.1.2