Peter, >first, great job paul! the phoenix blocks and app listener made it super-easy >to plug into the phoenix side of my application. > Vinay has done loads too .. :-)
>i'm wondering how to best handle the client side (currently cocoon2). I am >going to use the SocketObjectStreamSubscriber just by adding it as a >component to cocoon. I'm curious as to its thread safety and its intended >general usage pattern. > It is thread safe at the momnent because individual requests from however many threads on the client side have to queue for access to the connection Vinay has given me some code that multiplexes requests over the connection. This code also does callbacks. However I have serious problems with my codebase, that stem from some real change in the last week, but I cannot track it (more later), >Since it is designed to be a phoenix block, I'm guessing that it will be okay >to subclass and make ThreadSafe so the ECM in cocoon treats it right? > Not needed I think. The solutions we are aiming at sould allow multiple threads to use the same client to server connection. >How about usage then? I was just going to do lookup()'s, but what about >calling close() in such an environment, should close() only be called when >the component is shutting down (ie also implement Startable and call it in >the stop() method)? > Yes in the context of the phoenix block. >I haven't actually gotten to the point of *running* with the altrmi stuff, >still retrofitting my code. > Work with the tests in excalibut-altrmi first... There are limitations to the use of AltRMI. Some of which we roll back thr frontiers on, other may be more elusive (a method that returns a stream is out of reach at the moment). Regards, - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
