Re: Piggyback message support

> > I'm working on adding piggybacking support to the profile for standards
> > compliance and to aid in testing with our beepcore-java version of the
> > profile. As I see it, there are 4 areas where piggybacked messages need
to
> > be taken care of:
> >
> > 1) sending from the client
> > 2) receiving on the server
> > 3) replying from the server
> > 4) receiving the reply on the client
> >
> > Our current code supports 1) and 2), but I've been having a bit of
trouble
> > with 3) and 4).
> >
> > I suspect that I can get 3) to work on an endpoint server once I figure
out
> > what function to call to set the piggyback response message. However,
> > problems arise if the server is acting as a proxy for the tunnel
profile. A
> > response cannot be sent until the entire tunnel has been setup, or setup
has
> > failed (ok or error message). I've tried to complete the setup of the
next
> > connection from within tunnel's server_init function, but it seems to
get
> > hung at the point where I try to open a new tcp beep connection to the
next
> > hop (rr_tcp_connection_new). Currently I'm getting around this problem
by
> > spawning off a thread to finish the setup and then send a
non-piggybacked
> > reply so that the server_init function is allowed to return. Since that
> > method works, I'm guessing my problem is due to some sort of deadlock
> > condition within the roadrunner libraries. Is this the case? Is there a
> > work-around? Am I missing something?
>
> You are correct, RoadRunner uses a fixed size thread pool. The current
> default size of this pool is 1 (to make it easy to find this type of
> problems).
>
> Because of the fact that the maximum number of threads might be lower
> then the maximum number of allowed connections you aren't allowed to do
> certain things from within the profile. To avoid deadlocks you are not
> allowed to call functions that require free work threads (like
> rr_tcp_connection_new) from the functions
> (client/server)_(init/confirmation), close_(indication/confirmation) and
> frame_available.
>
> One workaround that might work is to call:
>
> rr_set_max_work_threads (x);
> rr_listener_set_max_connections (listener, y);
>
> where x >= y to make sure there always is free threads available.

I tried this (listener max connections was set to 100, so I set the thread
max to 150) but it didn't seem to have any effect. Is there something that
has to be changed in the libraries to get this to work? I've also noticed
that closing a connection doesn't seem to work, as you say, but opening a
new tcp connection from within frame_available works just fine (but not from
server_init, as stated above.)

Thanks for all the help,
- Chip Bradford