Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 07 22:08
    jeremydmiller commented #583
  • Dec 07 21:29
    jeremydmiller edited #583
  • Dec 07 21:29
    jeremydmiller closed #580
  • Dec 07 21:29
    jeremydmiller commented #580
  • Dec 07 21:29
    jeremydmiller demilestoned #580
  • Dec 07 14:39
    jeremydmiller demilestoned #562
  • Dec 07 14:39
    jeremydmiller milestoned #562
  • Dec 07 12:51
    jeremydmiller commented #562
  • Dec 06 20:45
    jeremydmiller closed #574
  • Dec 06 20:45

    jeremydmiller on master

    Better Disposal mechanics to ge… (compare)

  • Dec 06 19:47
    jeremydmiller closed #582
  • Dec 06 19:47
    jeremydmiller commented #582
  • Dec 06 19:47

    jeremydmiller on master

    Little rename and method access… Local routing improvements, new… (compare)

  • Dec 06 18:45
    jeremydmiller closed #563
  • Dec 06 18:45

    jeremydmiller on master

    New Endpoint.ReplyUri() method New Endpoint.ReplyEndpoint() me… Little tweak to ReplyUri mechan… (compare)

  • Dec 06 18:44
    jeremydmiller commented #563
  • Dec 06 18:39
    jeremydmiller commented #563
  • Dec 06 18:39
    jeremydmiller commented #563
  • Dec 06 18:39
    jeremydmiller commented #563
  • Dec 06 16:18
    jeremydmiller closed #586
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
Mark Warpool
@CodingGorilla
@jeremydmiller Any word on #532 ?
Jeremy D. Miller
@jeremydmiller
Sigh, no. I could I guess actually sneak in some OSS time this afternoon though
Or tomorrow maybe
Svein Ellingsen
@lovmoen
Has there been a recent change in how Jasper uses Marten/database? When I started my project back in May, I set up marten backed persistence and everything worked falwlessly until I recently deployed my project with a fresh/empty database. Now I keep getting these exeptions: '[ERR] Running Recover persisted outgoing messages
Npgsql.PostgresException (0x80004005): 42P01: relation "public.jasper_outgoing_envelopes" does not exist' and 'Npgsql.PostgresException (0x80004005): 42P01: relation "public.jasper_incoming_envelopes" does not exist'. I set the marten option AutoCreateSchemaObjects to AutoCreate.All. Are there other (new?) initialization procedures that need to be performed?
Svein Ellingsen
@lovmoen
If I manually restore the tables from my old database, the exceptions go away.
Jeremy D. Miller
@jeremydmiller
Yeah, there has. I did a lot of work this spring to put the Sql Server backed persistence and Postgresql backed persistence on the same common core, so it got much less Marten-centric. Slightly different table structure now
The docs are up to date on how to seed your database, but I didn’t do anything for conversion:(
Svein Ellingsen
@lovmoen
Should have seen that Thanks! :)