Re: [beep4j-user] Concurrency issues

[Sam R. <sro...@wu...>]

On Mon, May 05, 2008 at 10:58:25PM -0700, Thomson, Martin wrote:
> Unfortunately for me, it's not the info I was hoping for.  The text you
> point out in Section 2.6.1 of RFC 3080 severely limits the usability of
> BEEP for asynchronous applications.  Interesting to note that beep4j
> seems quite capable of sending replies out of order...something that I'm
> quite happy about because it makes my asynchronous hack much easier.
> (that is, please don't fix this ;)

If its a protocol violation, it won't interop with other
implementations.

> As a side note - forcing synchrony on your callers limits the
> flexibility offered by the interface.  I see that as a bad idea.  To
> give an example - tasks assigned to a thread pool might be used to
> generate requests and process responses.  If the same thread from that
> pool generated a request to two channels (presumably in different
> tasks); only the second reply handler would be found by beep4j - the
> reply handler for the first would never see any response.

Its possible you are just not seeing how BEEP should be used to achieve
your goals. BEEP supports both serialized and parallelized interactions,
through the use of channels.

BEEP gives serial processing within a channel. This is really important
for applications when you want to do things in order. Example would be
an HTTP-like protocol over BEEP. send a DELETE "/a" msg, send a POST
"/a" msg. You want the resource deleted before you POST to create the
new one. Technically, BEEP doesn't force requests to be handled
serially, its up to the specific application profile designer to decide
how they want to handle requests, but it does force replying in order.

If you want asynchrony, like you want to DELETE "/a" and POST "/b", and
want them able to progress seperately, you use different channels.

It sounds like you have a pool of threads that should act independently
(one should not block while another is making a request).  In that case,
each should have its own independent channel. This can be done by
grabbing a free channel from a pool of them.

Here's a description of the issue, and some Vortex library functions
that help deal with it:

  http://www.aspl.es/fact/files/af-arch/vortex/html/group__vortex__channel__pool_ga7130833a4500c9647fd84a

Cheers,
Sam