jeremydmiller on master
Better Disposal mechanics to ge… (compare)
jeremydmiller on master
Little rename and method access… Local routing improvements, new… (compare)
jeremydmiller on master
New Endpoint.ReplyUri() method New Endpoint.ReplyEndpoint() me… Little tweak to ReplyUri mechan… (compare)
First, this message:
Jasper.Messages:Information: Successfully processed message UpdateFeatureSubscriptions#016cd11a-6c35-483d-a028-fbfe4a5535f4 from loopback://retries/
MessageLogger.MessageSucceeded()
which is hard coded to report the "loopback://retries/" URL (which is called ReplyUri??), no matter what. The other logging I added seems to indicate it's actually coming from "loopback://durable/"
JasperOptions.ScheduledJobs.FirstExecution
and JasperOptions.ScheduledJobs.PollingTime
, which seems to control the durability agent's queue processing. I set them both to 2 minutes (default of 0 seconds and 5 seconds respectively), and the problem seems to go away.
DurabilityLoopbackSendingAgent.StoreAndForward()
.
.StoreAndForward()
initially saves the message as an incoming message with an OwnerId
of 0 (= AnyNode), and then immediately throws it into it's WorkerQueue
, which will start running the handler regardless of the "owning node". Then, since the RecoverIncomingMessages
fires every 5 seconds by default, assuming the handler takes longer than 5 seconds to run, it will see the message sitting in the incoming messages table, and "recover it" and run it again.