search

vlingo / xoom-actors

The VLINGO XOOM platform SDK for the type-safe Actor Model, delivering Reactive concurrency, high scalability, high-throughput, and resiliency using Java and other JVM languages.
https://vlingo.io
Mozilla Public License 2.0
229 stars 28 forks source link

ManyToOneConcurrentArrayQueueMailboxActorTest fix #104

Closed bwehrle closed 2 years ago

bwehrle commented 2 years ago
VaughnVernon commented 2 years ago

@bwehrle Ah, great catch.

  1. Does the setUp() represent what you want to do dynamically at runtime, to create a completely new mailbox type on the fly? This would provide the means to configure a number of M:1 mailbox types with different:
  1. Still we intend to implement the means to get a new instance of any given M:1 mailbox for a single actor instance (mailbox instance 1:1 actor instance).

Are you looking more for 1 or 2, or are both suitable? I consider 1 and 2 complementary, so there should be no conflict should you decide to use approach 1 and only use one total instance of that mailbox type ever rather than multiple/many as 2 provides.

I hope this makes sense. /cc @pflueras

bwehrle commented 2 years ago

Hi @VaughnVernon , I don't consider this PR to address the need to create mailboxes dynamically. Could this same code be used to do this post-setup time? If so, that at least demonstrates how it is possible. Ideally, I'd make this automatic by a "mailbox creator plugin"- because otherwise it seems like we're abusing the plugin system a bit.

I found another bug in the code in the mailbox implementation - the actor can cause a deadlock if sending to a full queue. This blocked my previous commit. Please check the proposed approach. I can think of other approaches, but this is at least a minimally workable solution.

VaughnVernon commented 2 years ago

@bwehrle I looked at this but I was not certain about the proposed fix. I am merging it to give you a runway but perhaps provide a longer-term solution. I think there are multiple was to solve this. What you have proposed will require the developer to deal with the supervision decisions and what the actor can do about those. I think I'd rather provide a way for the actor to succeed, because a self message should take precedence over client messages.