You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Royal <pr...@managingpartners.com> on 2002/04/10 22:35:35 UTC
[altrmi] usage questions
first, great job paul! the phoenix blocks and app listener made it super-easy
to plug into the phoenix side of my application.
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.
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?
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)?
I haven't actually gotten to the point of *running* with the altrmi stuff,
still retrofitting my code.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] usage questions
Posted by Peter Royal <pr...@managingpartners.com>.
On Friday 12 April 2002 02:06 am, Paul Hammant wrote:
> The OpenConnection (hidden from you) establishes 'session' . If X is
> bought back on lookup and given a refId (hidden again) of 123, andy
> other lookup on it is just going to give the same instance and refId.
good to know. I'm slowly digesting the altrmi internals to figure out all the
magic.
> Harmless. Having said that, I would split my app into two ... a
> container concept that knows of AltRMI and does the lookup, and a comp
> tha uses it, and has no handle on the interface that can be used for
> lookup. I think you have moved beyong the cornerstone transport
> packaged yes?
I'm using the cornerstone blocks on the server side for publishing, but yes I
moved beyond the cornerstone pieces for the client (which is good, since I
don't really need the phoenix-client.jar there either).
I thought about splitting the altrmi bits into two components, but I would
end up with a component that handles the altrmi and another component that
returns my work interface. But I've seen posts that having components that
are intrinsicly linked like that is bad component design, so each consumer of
the altrmi interface gets a handle to the component that can return an
AltrmiInterfaceLookup and passes that to a static method in a helper class to
return the work interface. Works well enough for the time being, there will
be chances to refactor in the future :)
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] usage questions
Posted by Peter Royal <pr...@managingpartners.com>.
On Friday 12 April 2002 02:11 am, Paul Hammant wrote:
> >The class in question had an import statement to a class that was not in
> > the servers classpath, and thus the exceptions. I figured it out when I
> > changed the method definition on the server method that was being called
> > to be the concrete class that was being passed rather than the interface.
>
> Yes, that is going to lead to loads of problems in the future. What is
> a facade and what is a value object requires intricate knowledge of the
> class model in question. I think a fail amount of support will be on
> that, unless AltRMI can be smart enough to issue appropriate messages.
Does standard RMI send needed .class files over the connection to the server
if the objects are not in its classpath? Its definitely doing something
different because with java rmi I didn't even have to put the specific class
that was being sent in the server's classpath. (I think I described that
correctly :)
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] usage questions
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>I was also getting this sending one of my classes from the client to the
>>server (most things go from server->client, this is the most complex thing
>>going back to the server):
>>
>
>success! learn something new every day. The altrmi behavior is different from
>the standard RMI behavior, I'm not sure why.
>
>The class in question had an import statement to a class that was not in the
>servers classpath, and thus the exceptions. I figured it out when I changed
>the method definition on the server method that was being called to be the
>concrete class that was being passed rather than the interface.
>
Yes, that is going to lead to loads of problems in the future. What is
a facade and what is a value object requires intricate knowledge of the
class model in question. I think a fail amount of support will be on
that, unless AltRMI can be smart enough to issue appropriate messages.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] usage questions
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 11 April 2002 05:49 pm, Peter Royal wrote:
> I was also getting this sending one of my classes from the client to the
> server (most things go from server->client, this is the most complex thing
> going back to the server):
success! learn something new every day. The altrmi behavior is different from
the standard RMI behavior, I'm not sure why.
The class in question had an import statement to a class that was not in the
servers classpath, and thus the exceptions. I figured it out when I changed
the method definition on the server method that was being called to be the
concrete class that was being passed rather than the interface.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] usage questions
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>>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.
>>
>
>I meant each call to lookup(), which it does. Most excellent! Any known
>harm's to calling lookup() multiple times on an AltrmiInterfaceLookup w/o
>corresponding close() calls?
>
No,
The OpenConnection (hidden from you) establishes 'session' . If X is
bought back on lookup and given a refId (hidden again) of 123, andy
other lookup on it is just going to give the same instance and refId.
Harmless. Having said that, I would split my app into two ... a
container concept that knows of AltRMI and does the lookup, and a comp
tha uses it, and has no handle on the interface that can be used for
lookup. I think you have moved beyong the cornerstone transport
packaged yes?
>>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.
>>
>
>I briefly looked at JAAS for my own app's security but decided against it for
>something much simpler and home grown. I may be interested in that in the
>future, mainly to authenticate against NT/W2k domains (but from what I read
>that's kinda a pain due to missing/incomplete docs)
>
My only lingering fear is that it is Thread-context using and thus will
hugely change AltRMI.
>>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.
>>
>
>I broke down and wrote one :)
>
>It is modeled after Berin's JdbcConnectionPool (ie copy-class in IDEA and
>change as neeed). I need to get a formal "yes" from management here before
>contributing back as it'll be the first non-patch donation and I want to make
>sure all the i & t's are covered.
>
IDEA is sooo cool :-)
Fingers crossed!
>>Thank us when it is bullet proof :-)
>>
>
>I'll try and help you get there. Otherwise my initial tests went well.
>
>I was also getting this sending one of my classes from the client to the
>server (most things go from server->client, this is the most complex thing
>going back to the server):
>
>java.io.StreamCorruptedException: Type code out of range, is 1
> at java.io.ObjectInputStream.peekCode(ObjectInputStream.java:1556)
> at
>java.io.ObjectInputStream.skipToEndOfBlockData(ObjectInputStream.java:1480)
> at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1216)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
> at
>org.apache.excalibur.altrmi.server.impl.ServerObjectStreamReadWriter.readRequest(ServerObjectStreamReadWriter.java:78)
> at
>org.apache.excalibur.altrmi.server.impl.ServerObjectStreamReadWriter.writeReplyAndGetRequest(ServerObjectStreamReadWriter.java:66)
>
>The class was simply Serializable with no UID set.
>
>Then I made it Externalizable and set a UID and started getting
>
>java.io.InvalidClassException:
>com.pace2020.appbox.common.objectbundle.ValidatedBundle; Local class not
>compatible: stream classdesc serialVersionUID=-1436348206578395418 local
>class serialVersionUID=0
> at
>java.io.ObjectStreamClass.validateLocalClass(ObjectStreamClass.java:523)
> at java.io.ObjectStreamClass.setClass(ObjectStreamClass.java:567)
> at
>java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:936)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
> at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
>
>Which is odd because they both have the same class file!
>
>I will mess around more later tonight, stripping down the class until it goes
>through and then adding back data members to see what the cause is. But if
>you have any ideas off the top of your head! :)
>
Did you remember super.externalize() ? And that it is FIFO no LIFO ?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] usage questions
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 11 April 2002 02:03 am, Paul Hammant wrote:
> >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.
I meant each call to lookup(), which it does. Most excellent! Any known
harm's to calling lookup() multiple times on an AltrmiInterfaceLookup w/o
corresponding close() calls?
> 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.
I briefly looked at JAAS for my own app's security but decided against it for
something much simpler and home grown. I may be interested in that in the
future, mainly to authenticate against NT/W2k domains (but from what I read
that's kinda a pain due to missing/incomplete docs)
> 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.
I broke down and wrote one :)
It is modeled after Berin's JdbcConnectionPool (ie copy-class in IDEA and
change as neeed). I need to get a formal "yes" from management here before
contributing back as it'll be the first non-patch donation and I want to make
sure all the i & t's are covered.
> Thank us when it is bullet proof :-)
I'll try and help you get there. Otherwise my initial tests went well.
I was also getting this sending one of my classes from the client to the
server (most things go from server->client, this is the most complex thing
going back to the server):
java.io.StreamCorruptedException: Type code out of range, is 1
at java.io.ObjectInputStream.peekCode(ObjectInputStream.java:1556)
at
java.io.ObjectInputStream.skipToEndOfBlockData(ObjectInputStream.java:1480)
at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1216)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at
org.apache.excalibur.altrmi.server.impl.ServerObjectStreamReadWriter.readRequest(ServerObjectStreamReadWriter.java:78)
at
org.apache.excalibur.altrmi.server.impl.ServerObjectStreamReadWriter.writeReplyAndGetRequest(ServerObjectStreamReadWriter.java:66)
The class was simply Serializable with no UID set.
Then I made it Externalizable and set a UID and started getting
java.io.InvalidClassException:
com.pace2020.appbox.common.objectbundle.ValidatedBundle; Local class not
compatible: stream classdesc serialVersionUID=-1436348206578395418 local
class serialVersionUID=0
at
java.io.ObjectStreamClass.validateLocalClass(ObjectStreamClass.java:523)
at java.io.ObjectStreamClass.setClass(ObjectStreamClass.java:567)
at
java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:936)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
Which is odd because they both have the same class file!
I will mess around more later tonight, stripping down the class until it goes
through and then adding back data members to see what the cause is. But if
you have any ideas off the top of your head! :)
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] usage questions
Posted by Paul Hammant <Pa...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] usage questions
Posted by Peter Royal <pr...@managingpartners.com>.
On Wednesday 10 April 2002 05:49 pm, Paul Hammant wrote:
> >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 .. :-)
indeed! (didn't mean to forget you Vinay :)
> 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?
> 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.
> >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.
> >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.
thanks!
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] usage questions
Posted by Paul Hammant <Pa...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>