Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 17:36
    jeremydmiller edited #577
  • 17:35
    jeremydmiller opened #577
  • 16:54
    jeremydmiller opened #576
  • 16:03
    jeremydmiller milestoned #575
  • 16:03
    jeremydmiller opened #575
  • 16:01
    jeremydmiller milestoned #574
  • 15:54
    jeremydmiller opened #574
  • 15:43
    jeremydmiller milestoned #573
  • 15:43
    jeremydmiller opened #573
  • Nov 18 15:28
    jeremydmiller commented #569
  • Nov 14 22:26
    jeremydmiller edited #567
  • Nov 14 22:22
    jeremydmiller closed #572
  • Nov 14 22:22

    jeremydmiller on master

    Killed IWorkerQueue.ScheduledJo… Introduced the new Envelope.Mar… Introduced the static Envelope.… and 6 more (compare)

  • Nov 14 22:21
    jeremydmiller milestoned #571
  • Nov 14 22:21
    jeremydmiller milestoned #570
  • Nov 14 22:21
    jeremydmiller milestoned #569
  • Nov 14 22:21
    jeremydmiller milestoned #568
  • Nov 14 22:21
    jeremydmiller milestoned #567
  • Nov 14 22:21
    jeremydmiller milestoned #566
  • Nov 14 22:21
    jeremydmiller milestoned #564
Jeremy D. Miller
@jeremydmiller
I’d love to see how you’re making that happen. This is all from posting to a local, persistent queue, right?
And you’re not stopping and starting anything in between somehow, right?
Mark Warpool
@CodingGorilla
This is all running on my local development machine. Yea, it's all from a call to ICommandBus.EnqueueDurably()
nope, like I said I have to remove all the breakpoints except inside the handler, or the behavior goes away
Jeremy D. Miller
@jeremydmiller
Is there something from the routing rules that’s routing it to both queues?
Hey, I’ve got to turn in, but I’ll check this when I can tomorrow.
Mark Warpool
@CodingGorilla
Not as far as I can tell, I really only have the local queue, I'll keep digging around until I'm ready to pass out myself. Good night :)
Jeremy D. Miller
@jeremydmiller
ttyl
Mark Warpool
@CodingGorilla
So a couple of observations:

First, this message:

Jasper.Messages:Information: Successfully processed message UpdateFeatureSubscriptions#016cd11a-6c35-483d-a028-fbfe4a5535f4 from loopback://retries/

Seems misleading, it seems like after a message is processed it always calls 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/"
Second, I changed the 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.
Mark Warpool
@CodingGorilla
But along with the problem going away, I also notice that the message is no longer being picked up by the RecoverIncomingMessages queue from the durability agent. But I still cannot figure out where the actual execution comes from.
I'm sure I'll be back, banging my head on this wall in the morning, I hate a puzzle I can't solve =D
Mark Warpool
@CodingGorilla
Oh, I think I figured it out, if I understand incoming messages structure properly, an OwnerId of 0 means "AnyNode". EnqueueDurably() calls down into persistOrSend, which since there isn't an ongoing transaction, calls Envelope.Send(). This in turn calls the DurabilityLoopbackSendingAgent.StoreAndForward().
Mark Warpool
@CodingGorilla
This is where the problem is. .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.
BOOM, problem identified. Gotta sleep now. =)
Jeremy D. Miller
@jeremydmiller
Yup, that would do that. Awfully good catch.
Jeremy D. Miller
@jeremydmiller
And a one line code fix:/
Mark Warpool
@CodingGorilla
Is the fix to just make.StoreAndForward() save it with the current node id?
Jeremy D. Miller
@jeremydmiller
Yes
Mark Warpool
@CodingGorilla
Makes sense...
Mark Warpool
@CodingGorilla
Would you like me to prepare a pull request? Or have you got it?
Jeremy D. Miller
@jeremydmiller
I’ll take a PR, or I’m going to be back in Jasper for other reasons in the next week I think
Mark Warpool
@CodingGorilla
#532 Is ready to go
Jeremy D. Miller
@jeremydmiller
:thumbsup:
Got it
or will very soon
Mark Warpool
@CodingGorilla
Thanks, we have a big release of a different product next week, so I have a little breathing room on this particular issue, so no rush.
That and I put a bunch of locking on the handler to make sure it can't run twice at the same time for the short term =)
Svein Ellingsen
@lovmoen
Is there a way to perform a remote async "request/response" in the same way as Invoke<TResponse>()?
Jeremy D. Miller
@jeremydmiller
I don’t remember if that got yanked out or not, but there used to be an Request() method for that. I think I eliminated that in the thinking that you’d just use HTTP. That was some significant complexity
Svein Ellingsen
@lovmoen
OK, thanks for your quick response! I'll just have to figure a way around that then.
Svein Ellingsen
@lovmoen
On another note: The documentation doesn't really explain well the difference between SendAndExpectResponseFor, Send and Publish. Reading the section on "Send Message with Eventual Reply" it just shows a call to SendAndExpectResponseFor which looks just like a call to Send or Publish. A section explaining how these behave differently would be very helpful.
Svein Ellingsen
@lovmoen
@jeremydmiller I refer you to our discussions back in june; I had some trouble with scheduled messages. Since then I have been on vacation and later busy with other projects, but now I have this project on the top of my priority list again. I was wondering if you'd had any more time to look into the issues I raised wrt ScheduleSend and durable/non-durable queues. Also, I have now come a bit further in my project, and have implemented a saga whose Starts() method returns messages for future processing. I return an IEnumerable<object> of ScheduledResponse objects which should be sent out at a future time. But the behaviour I'm getting is immediate processing of these messages.
Svein Ellingsen
@lovmoen
Would I be better off using IMessageContext.ScheduleSend directly instead, injecting the IMessageContext into my saga object?
Svein Ellingsen
@lovmoen
I tried that approach, but ScheduleSend with a time in the future still sends the messages immediately.
Svein Ellingsen
@lovmoen
Sorry, not so! When converting correctly between local and UTC, Jasper does exactly what it says on the tin! My bad. Will check and report back on whether all my woes with scheduled messages have been due to poor timezone management on my part.
Svein Ellingsen
@lovmoen
Yep. That makes it work equally well when returning ScehduledResponse objects from the saga start handler.
Svein Ellingsen
@lovmoen
The problem I mentioned back in june remains, however: If I do Schedule to a queue, nothing happens. If I do ScheduleSend, it gets processed immediately if the queue is durable, and at the expected time if ithe queue is non-durable.
The behaviour can be reproduced with the example code I put on github: https://github.com/lovmoen/myjaspertest/tree/schedule-durable-queue
Jeremy D. Miller
@jeremydmiller
There was a bug about the scheduled messages going to a loopback queue, that was real.
I remember this conversation from back then. Are you on the latest now?
Svein Ellingsen
@lovmoen
Just tested on 0.9.13.
Jeremy D. Miller
@jeremydmiller
Nevermind that, I don’t see anything in the commit history for that.
I’ll try to get into that this weekend. I was just about to do some other work on Jasper anyway
Svein Ellingsen
@lovmoen
That's great! I just pushed my updated code to the above git repo if that's of any help.
Jeremy D. Miller
@jeremydmiller
Okay, thanks. I’ll definitely try to take a look soon
ddivita
@ddivita
What does the roadmap look like for .net Core 3?
Jeremy D. Miller
@jeremydmiller
Wait for aspnetcore 3.0 to come out, convert over to that, and finally kick out a 1.0