[omniORB] Re: OmniEvents and threading

[bjorn rohde jensen]

Hi Bruce,

  Thanks alot for sharing your ideas and experience
with implementation of EventServices:) I have come
to many of the same conclusions as you, which i
take to mean, i cant be completely wrong....
  I have been toying with the idea of using Finite
State Machines for the proxy objects to provide
sufficient flexibility with respect to QoS parameters.
It might be a bit overkill to use FSM's to model
a 4 state connection. My mock-up just used 4 small
while loops, but i would like more elegant solution.
  To thread or not to thread is indeed the question
and in your particular case, threading would hardly
have simplified things. I think, it would be a good
idea in combination with individual queues for a more
generic event service, since i am reluctant to drop
clients quite as freely, as you describe. Implementing
an exponential back-off mechanism and individual
queues was not terribly hard, and i cant really
think of a simple way to support PullConsumers without
individual queues, so it would not add much complexity
to the whole. Having seperate threads animate the
active proxies would limit the impact of badly behaving
clients just like your timeout but at the cost of using
a limited system resource aka threads or introduce a
thread pool.
  I also worry a lot about the foot-print of the
implementation, which is rather at odds with all the
fancy QoS options, TypedEvents and such, i would like
omniEvents to support.
  Any thoughts, system requirements ideas and
experiences with respect to omniEvents and event
services in general are quite welcome:)

Yours sincerely,

Bjorn