These are chat archives for JasperFx/jasper

17th
Apr 2018
MedAnd
@MedAnd
Apr 17 13:32

Hi @jeremydmiller, continue to closely follow this project having just read your latest blog post... wondering:

how much support Dapper will receive in terms of feature parity/integration compared to Marten?
is it too early to share performance numbers... how many messages can Jasper persist to PG via Marten, process etc?
is Kestrel a supported inter-process transport... plans for gRPC, MessagePack etc?

Jeremy D. Miller
@jeremydmiller
Apr 17 13:33
@mikerdean Thank you, that’s enough to help me get that along. How would you feel about that just being in the base Jasper lib? How stable is MessagePack do you think?
MedAnd
@MedAnd
Apr 17 13:34
I see support for MessagePack taking shape before my eyes :-)
Jeremy D. Miller
@jeremydmiller
Apr 17 13:35
@MedAnd Kestrel is already supported as a transport type. As for performance, we’re just about ready to do some serious load testing with the Marten-backed persistence among other things. It actually skips the document storage and goes raw to ADO.Net.
MessagePack you just saw;)
gRPC — totally different ball game. I don’t know what or how Jasper would fit into that. Protobuf as a serialization option though, definitely.
For Dapper, I just barely spec’d that out a wee bit today. I don’t think the outbox implementation will be quite as slick as the Marten one in that blog post, but I’m thinking you’d have full feature parity otherwise. So subscription, node discovery, message, and saga state persistence.
Some of the “durable messaging” bit of that will have to be database centric though, even if the Dapper/EF bits aren’t.
MedAnd
@MedAnd
Apr 17 13:37
cool... so Protobuf for the message format... but maybe not using the Google C gRPC library....
Jeremy D. Miller
@jeremydmiller
Apr 17 13:38
Yes. If you go full gRPC, you wouldn’t really want something like Jasper, unless I’m missing something. I think Jasper adds a lot of value in the message handling, routing, and other things you wouldn’t get from gRPC though
MedAnd
@MedAnd
Apr 17 13:45
currently using Dapper in one of my projects with PostgreSQL and asking some questions on the Marten group :-) but also looking into Jasper.... one area of specific interest is in the processing of messages logic... can I implement my own "message processing logic" by implementing some Jasper interfaces & configuring IoC?
Jeremy D. Miller
@jeremydmiller
Apr 17 13:46
What do you mean, “message processing logic”?
MedAnd
@MedAnd
Apr 17 13:47
I'm currently using the .Net TPL/Dataflow blocks
Jeremy D. Miller
@jeremydmiller
Apr 17 13:47
Which is what Jasper uses internally too for the actual message handling
MedAnd
@MedAnd
Apr 17 13:48
About 1+ month ago I looked at that code, from memory I wanted to add more blocks :-)
Jeremy D. Miller
@jeremydmiller
Apr 17 13:50
For what reasons? Nothing stopping you from having a Jasper message handler just drop things off into your own action blocks
MedAnd
@MedAnd
Apr 17 13:57
The platform uses Service Fabric... stateful services, we keep track of certain state per message or group of messages then take different actions...
Thinking of using Jasper within Service Fabric... any experience in this area?
mikerdean
@mikerdean
Apr 17 13:58
@jeremydmiller I'm fine with it being in the base library, although obviously it has an extra dependency (which you may or may not want). MessagePack for C# seems stable enough for me so far although I really haven't put anything incredibly complicated through it yet. It's mostly plug and play, provided you give it POCO objects as far as I've tested.
Jeremy D. Miller
@jeremydmiller
Apr 17 13:58
Nope, but I’d be curious to try to think through what that would be like. My shop is
stuck in the stone ages and not doing any kind of cloud hosting quite yet
MedAnd
@MedAnd
Apr 17 13:59
I think the .Net Core team is adopting MessagePack for the new .Net Core SignalR...
Jeremy D. Miller
@jeremydmiller
Apr 17 13:59
@mikerdean It’s not particularly much work to make a drop in extension
MedAnd
@MedAnd
Apr 17 14:00
@jeremydmiller thinking if I can find the time I could even add support for Service Fabric reliable collections as one of the persistence options...
Jeremy D. Miller
@jeremydmiller
Apr 17 14:00
@MedAnd W/o digging into the TPL blocks, you can use Jasper’s flavor of middleware to handle cross cutting concerns if that would help
@MedAnd I’d happily take that. I’m just about to start working on the other persistence options, and that should help to shake out the patterns and plug in points a bit
MedAnd
@MedAnd
Apr 17 14:03
@jeremydmiller if I can find the time that would be a good PoC/integration exercise for me as well... to learn Jasper in more detail
in Jasper... are you using Polly or something similar?
Jeremy D. Miller
@jeremydmiller
Apr 17 14:05
Comes from what we use in fubu today, so it predates Polly by quite a bit. I thought about trying to replace it w/ Polly, but I thought that was more work than it was worth and Polly forces you to do so many more memory allocations than what the fubu/jasper approach already did
MedAnd
@MedAnd
Apr 17 14:07
cool with that, having less dependencies, less allocations all a plus... but have to ask... exponential backoff?
Jeremy D. Miller
@jeremydmiller
Apr 17 14:17
Huh?
Ah, gotcha. You can set limits on the maximum number of attempts. You can also specify that certain exception types are automatically handled by shoving the messages to an error queue. You could have a custom error handler that’s a touch smarter to make the delay before a retry take longer for more failure attempts
JasperFx/jasper#364