Message ignored after disposal?
Jose de Castro
Firs off, thanks for all the work that went into this library. It's
great to see a lightweight alternative to some of the other Actor
frameworks. I've been hacking away o a project for a couple week and
am very impressed with the simplicity and performance so far.
I have a question though...
Why ignore messages if the Fiber is disposed? Would it not be better
to have "publish" return a boolean or throw an exception? I've had to
work around this by wrapping my Fiber and Channel in a class that
keeps track of the Fiber's "running" state and rejects messages if
there is no chance of them being processed. It seems awkward for the
Executor to accept the message if it plans on dropping it on the
floor.
Mike Rettig
In the apps I work on, I want those events ignored b/c the system is
shutting down.
The publish event cannot return a boolean b/c the event just gets
queued at that point so there still is no guarantee that the event
ever gets executed. Java Executors solve this problem by providing a
rejected execution interface. This allows the creator of a thread pool
to decide what to do with rejected events. One way doesn't work for
everyone, but the current approach to ignore events on disposal works
for the majority of cases I've encountered.
Is your app shutting down? Why was the Fiber disposed?
Mike
> --
> You received this message because you are subscribed to the Google Groups "jetlang-dev" group.
> To post to this group, send email to jetla...@googlegroups.com.
> To unsubscribe from this group, send email to jetlang-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jetlang-dev?hl=en.
>
>
Jose de Castro
I'm fine with queued events firing after disposal; actually I prefer
it that way. The issue is that ChannelSubscription accepts new
messages after the fiber has been disposed which results in the
message being dropped on the floor (see PoolFiber.execute). If only
the ChannelSubscription had some way of checking the running state of
the Fiber I could get close to what I'm looking for.
A little background... We're working on the next generation of our
real-time telephony platform (http://tropo.com). Each phone call is
represented by it's own actor/Fiber. External clients can control
these calls by sending them command messages (e.g. Hangup, PlayAudio,
etc.). The issue is that the publisher of the message has no way of
knowing if the message will be processed and therefore cannot reply to
the client with an appropriate error.
The behavior I'm looking for may not be possible with Jetlang's
current architecture. The one-to-many relationship between Channel and
Fiber makes it very tricky to atomically publish a message without a
significant contention :-(
Thanks again for the quick response,
Jose de Castro
Chief Architect
Voxeo Labs
http://tropo.com
On Apr 20, 10:17 am, Mike Rettig <mike.ret...@gmail.com> wrote:
> It is very common to receive events after a fiber has been disposed.
> In the apps I work on, I want those events ignored b/c the system is
> shutting down.
>
> The publish event cannot return a boolean b/c the event just gets
> queued at that point so there still is no guarantee that the event
> ever gets executed. Java Executors solve this problem by providing a
> rejected execution interface. This allows the creator of a thread pool
> to decide what to do with rejected events. One way doesn't work for
> everyone, but the current approach to ignore events on disposal works
> for the majority of cases I've encountered.
>
> Is your app shutting down? Why was the Fiber disposed?
>
> Mike
>
Mike Rettig
> Thanks for the quick response Mike.
>
> I'm fine with queued events firing after disposal; actually I prefer
> it that way. The issue is that ChannelSubscription accepts new
> messages after the fiber has been disposed which results in the
> message being dropped on the floor (see PoolFiber.execute). If only
> the ChannelSubscription had some way of checking the running state of
> the Fiber I could get close to what I'm looking for.
>
> A little background... We're working on the next generation of our
> real-time telephony platform (http://tropo.com). Each phone call is
> represented by it's own actor/Fiber. External clients can control
> these calls by sending them command messages (e.g. Hangup, PlayAudio,
> etc.). The issue is that the publisher of the message has no way of
> knowing if the message will be processed and therefore cannot reply to
> the client with an appropriate error.
Why is another thread disposing the fiber? I would handle this by
having the same fiber/thread dispose the thread that publishes to it.
If the same fiber is used, then it can update state accordingly to
know that a fiber is disposed prior to the publish.
The key to using jetlang (and most threading problems) is to try to
make all problems into isolated single-threaded, sequential units of
work. All state changes must be processed by the same fiber/thread.
The disposal of the fiber is a state change that the publisher must
know about prior to the publish.