Peter, >>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 >> > >good to know, I'll just make it poolable for the time being. > >It appears that the authentication information is passed on each remote >method invocation, correct? > Not so. There are two methods for use at the lookup stage. One has an (untested) authentication parameter. Once the lookup has a returned the remote refernece, it there is no sunsequent passing of authentication stuff.
A guy called Juozas Baliuka (whom gerhard works with for SimpleStore in Commons) says that JAAS should be targeted for compatibility. We also have an issue re transactions. In EJB, transaction is not passed as a paremter on methods but as ssomething that is associated with the thread. If we go down that road, then thread safety will be affected (referring to your prev questions). It has not been settled yet as we were pushing towards distributed garbage collection and callbacks. >>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), >> > >Excellent! I saw the later email about how that has been commited. I do need >callbacks, but I may implement them as a separate publish/subscribe >temporarily. > I have a gut feeling that transports that use callback will not easily be recoverable. Currenetly the request/reply transports are easily recoverable during outage. >>>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. >> > >I do need to subclass to put a lifestyle interface on it to use it in a >non-phoenix environment. The ECM will make it single-threaded if it isn't >marked ThreadSafe or Poolable. > Leid uses AltRMI in Instrument. It could be useful to have some Component wrapper (optional packages) for an increased integration with Avalon family applications. The design was driven from a bean perspective though -> A tool that can be instantiated and used by any client or server app, with few external dependencies. There is a dependence on LogKit (via framework). I'd like to see more use of Threadpool and other excalibur comps, but only as optional replacements for default non-dependent bits of AltRMI. I.e. A person developing a Swing GUI, should not need to bunble too many other jars, as in their mind's eye Avalon is not a good fit for client side Java. >>>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). >> > >I'm going full bore :) I need the speed increase + the potential to put >inside the same JVM. All I'm doing is passing Serializable objects back and >forth and it appears that piece is down pat. Plus it'll be a good stress >test, we're kinda xp-ish over here so it'll be going into our internal >dogfooding. > Take a look at PipeTest. One of AltRMI's key usages is in joing mutually invisible classloaders in the same JVM. >thanks! > We're still at v0.6 dude ;-) Thank us when it is bullet proof :-) Regards, - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
