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
Oh, good point. Let me look into that
Mark Warpool
@CodingGorilla

Ok, so my thought is to add a new property to Frame: RequiresAwait, and then modify the MethodFrameArranger.Arange() as:

public void Arrange(out AsyncMode asyncMode, out Frame topFrame)
{
    var compiled = compileFrames(_method.Frames);

    asyncMode = AsyncMode.AsyncTask;

    if(compiled.Any(x => x.IsAsync) && compiled.Any(x => x.RequiresAwait))
    {
        asyncMode = AsyncMode.AsyncTask;
    }
    else if (compiled.All(x => !x.IsAsync))
    {
        asyncMode = AsyncMode.None;
    }
    else if (compiled.Count(x => x.IsAsync) == 1 && compiled.Last().IsAsync && compiled.Last().CanReturnTask())
    {
        asyncMode = compiled.Any(x => x.Wraps) ? AsyncMode.AsyncTask : AsyncMode.ReturnFromLastNode;
    }

    topFrame = chainFrames(compiled);
}

Thoughts?

Jeremy D. Miller
@jeremydmiller
I don’t think you need a new property on the frame. The IsAsync should be enough.
The case that screwed us is if ONLY the very last frame is IsAsync == true, but there’s another Frame somewhere that’s Wraps == true.
Mark Warpool
@CodingGorilla
well, if you want to just naively force an await on anything that is async, with this though, it would be "smarter"
Jeremy D. Miller
@jeremydmiller
I wonder if the Frame that wrote out the using statement was giving you the right Wraps value
It solves your problem fast. Returning the last task was just more optimal performance wise where you could get away with it
Mark Warpool
@CodingGorilla
what is Wraps indicative of?
Jeremy D. Miller
@jeremydmiller
That the frame does something that “wraps” the code in the following frames. So in the case of a using block, the prior Frame wraps code around the later frames
Mark Warpool
@CodingGorilla
The frame that caused the using was the ServiceScopeFactoryCreation, oh, and so yea it sounds like the ServiceScopeFactoryCreation should set Wraps to true, but it doesn't
So let me just change that quickly and see if that fixes the test
Jeremy D. Miller
@jeremydmiller
:thumbsup:
Mark Warpool
@CodingGorilla
HAHA, I spent like 12 hours on that, and it was a 3 second fix
Jeremy D. Miller
@jeremydmiller
Oh man, sorry about that. But it happens that way sometimes
Mark Warpool
@CodingGorilla
yea, no problem, it gave me a better understanding about how all the codegen works now :)
I'll submit a PR
Jeremy D. Miller
@jeremydmiller
Cool. Hoping things settle down for me next week so I can start processing OSS things again. Got at least a couple other things to do in both Jasper & Lamar
Jeremy D. Miller
@jeremydmiller
@CodingGorilla I think I’ll have a new Jasper release either tonight or tomorrow
Mark Warpool
@CodingGorilla
Great news, thanks! :+1:
Jeremy D. Miller
@jeremydmiller
It’s not huge, but there’s a Jasper v0.9.13 up today w/ some fixes for @CodingGorilla
Mark Warpool
@CodingGorilla
Thanks @jeremydmiller !
Stuart Clement
@jenart
Hey Guys, got a query regarding the correct/best practice for running Jasper within unit tests... I've put together a sample project on github to illustrate rather than trying to squeeze it all in here. Thanks in advance. Please see: [JasperTest] (https://github.com/jenart/JasperTest)
Mark Warpool
@CodingGorilla
@jeremydmiller I hate to bother you, but I have a major issue. I'm seeing an issue where Jasper seems to be running the handler for the same message twice concurrently.

In my debugging I end up seeing this:

Jasper.Messages:Information: Successfully processed message UpdateFeatureSubscriptions#016cbb46-b9f5-433d-86d0-23eaedc9e5e9 from loopback://retries/

in the output log, also, if I put a breakpoint at the top of the Handle method, that break point gets hit twice
Any thoughts on whether I might have something configured wrong that would cause this?
Mark Warpool
@CodingGorilla
Except maybe it only happens with the very first message it processes?
Jeremy D. Miller
@jeremydmiller
Can you try the diagnostic commands that spits out the handler code and see if that provides anything you don’t expect?
Can’t say that I’ve ever seen that
Mark Warpool
@CodingGorilla
No, seems totally normal, only one call to my handle method in the generated code
Jeremy D. Miller
@jeremydmiller
Ah, wait. It’s happening with retries? Seeing error messages too?
Mark Warpool
@CodingGorilla
it doesn't only do it on the first message, but it does seem to stop running the message handlers twice "after a while"
Jeremy D. Miller
@jeremydmiller
The presence of the retry queue makes me wonder a bit
Mark Warpool
@CodingGorilla
if I put enough break points, everything just !@#$ing works... :rage:
It was pretty consistently running it twice the very first message it processed after I started the debugger, not it seems totally random
Almost like if I'm paused in the debugger long enough it starts a new one? But I can't quite nail down the pattern.
Mark Warpool
@CodingGorilla
Sorry, my gitter died or something I didn't see your responses

Even when it only runs one time it always says:

Jasper.Messages:Information: Successfully processed message UpdateFeatureSubscriptions#016cbb46-b9f5-433d-86d0-23eaedc9e5e9 from loopback://retries/

I assume this means that it's running the message out of the "retry queue"?
And for clarification, when the handler runs twice, I see that same message in the output twice, with the same id after the "UpdateFeatureSubscriptions"
Mark Warpool
@CodingGorilla
the handler handles all errors on it's own, so the Handle() method can never throw an exception, so Jasper should have no reason to put it into retry
Jeremy D. Miller
@jeremydmiller
It does. Makes me wonder if your message is getting routed to multiple queues. Not sure why anything would make it to the retries queue though
W/o it being a failure
Jeremy D. Miller
@jeremydmiller
You know you can let Jasper handle the errors, right? It’ll log and apply retry policies
Mark Warpool
@CodingGorilla
Yes, in this case I can't let it just fall and retry, I need to handle the failure gracefully and do a sort of rollback.
Mark Warpool
@CodingGorilla
It's handles keeping things in sync with a bunch of third party APIs for billing and such
Mark Warpool
@CodingGorilla
@jeremydmiller So I noticed that when I get this duplicate message running, I see jasper log the following
Jasper.Transports:Information: Recovered 1 incoming envelopes from storage
Does that indicate that it's seeing that message as previously failed?
Mark Warpool
@CodingGorilla
It seems like it's queuing up the message on the loopback, but then the durability agent sometimes kicks in and recovers the message while it's still running from the "local queue"