[slaboure]

Hello,

Code has been updated on 3.1RC (HEAD). Can you try it please.

Cheers,

Sacha

[groovesoftware]

Sacha,

I appreciate your looking into this.

Using CVS HEAD from 7/30, it is not fixed. I was able to reproduce first try using Jetty this time instead of Tomcat and the instructions exactly as I gave them in the forum and in the bug report. I'm not sure that the timing issue you mention is the problem because there is no network involved and because the machine is fast. All servers are running on the same 4x800Mhz Sparc Solaris
box with 2gig of memory. I'm using JDK version 1.3.1_03-b03.

I know you're busy, and any of your time that you put into this is appreciated. Unfortunately it seems that I will not be the only one affected by this since I am able to reproduce it with such a basic example.

I will double-post this information to the bug report and the forum.

Thanks,
Matt Cleveland

[groovesoftware]

Sacha has discussed this extensively with me through email. Here is the conclusion to this problem.

--- Sacha Labourey wrote:
> Hello Matt,
>
> I understand your concern. while I think the actual behaviour is ok, I've
> modified the clustering code yesterday and will commit it today (this
> morning) to HEAD, and possible (if it doesn't impact too many things),
> Branch_3_2. I won't apply changes to Branch_3_0 (it must be stable wrt
> behaviour).
>
> You can then try and tell me if it works for you.
>
> cheers,
>
>
>
> Sacha
>
>
>
> > -----Message d'origine-----
> > De : Matt Cleveland
> >
> > Sacha,
> >
> > Thanks for your response. I understand what you are saying, but
> > I also think
> > my expectation will probably be a common one when dealing with Stateless
> > Session Beans. I believe the common usage pattern is to lookup a
> > reference to
> > the home, create the bean and make a call or two on the bean and
> > then destroy
> > it to allow the server to release the resources. This is more or
> > less implied
> > by the spec. Many people (like us) will cache the home
> > reference, but I don't
> > think people will normally cache the reference to the remote. We
> > can do that
> > in our case and I think it makes good sense because it saves a
> > network trip (on
> > the create call), but I doubt most people will write code this way.
> >
> > I guess another expectation I had was that the first call to a
> > bean would go to
> > the server it was created on and round-robin from there. Don't
> > know if that's
> > a reasonable expectation, or just me. Seems like if it doesn't I
> > have to go
> > out of my way (by caching the remote reference) to get fair
> > balancing over my
> > cluster (again assuming the session bean ussage pattern described above).
> >
> > It sounds like your proposal would fix the problem. Another
> > solution might be
> > a random load-balance policy. In the meantime I will cache
> > remote references
> > and move on. Will you be posting your answer back to the forum
> > so that others
> > can understand? I can also follow up in the forum with my plan for a
> > workaround.
> >
> > Thanks
> > Matt Cleveland
> >
> > --- Sacha Labourey wrote:
> > > Hello Matt,
> > >
> > > I've spent a few time trying to figure out what is not working
> > and I think
> > > that everything works fine: only our common understanding of
> > the goals is
> > > different.
> > >
> > > What you are trying to do, by default, is:
> > > - you create a single home object
> > > - you create many remote objects from this home and
> > > - make a single call on this remote to see the message
> > being displayed
> > >
> > > And what you would like to see is the "Ejb1" and "Ejb2" messages being
> > > displayed on each server in a round-robin fashion. Right?
> > >
> > > It won't work and this is absolutly normal. Let's go step by step.
> > >
> > > Create home:
> > > ============
> > > When you create your home, you get a proxy that contains the
> > full list of
> > > your 5 target nodes. The policy is set to round-robin so each
> > home call will
> > > target a different node.
> > >
> > > Create Remote:
> > > ==============
> > > Using the home proxy, you make a home.create() call. This will
> > target one of
> > > the three nodes and return a remote proxy also containing the
> > list of the 3
> > > target nodes. AT THIS POINT, NOTHING IS DISPLAYED ON ANY JBOSS INSTANCE
> > > SCREEN BECAUSE HOME.CREATE CALLS ARE NOT DIRECTED TO THE BEAN
> > > IMPLEMENTATION: IT IS A PURE CONTAINER CALL.
> > >
> > > Invoke method on remote:
> > > ========================
> > > As the proxy you've received is brand new (it is not reused),
> > it will take
> > > the first member in the target list. As the list has no particular order
> > > (depending from which node it comes), one of the 3 nodes is selected
> > > **randomly**.
> > >
> > > Next Remote Creation:
> > > =====================
> > > Using the same home proxy, you make, once again, a
> > home.create() call. This
> > > will target the *next* node and return a remote proxy. Again:
> > you will *not*
> > > see that this call has gone to another node, but it is the
> > case: it is just
> > > that nothing is displayed on this node's shell.
> > >
> > > Next invoke method on remote:
> > > ===========================
> > > As the proxy you've just received from your second home.create() call is
> > > brand new and not related to the remote proxy you had acquired
> > in the first
> > > home.create() call, it will select, in no specific order, a
> > first member in
> > > the target list as its target node. IT WILL POSSIBLY BE THE SAME AS THE
> > > PREVIOUS REMOTE.INVOKE CALL, YOU CANNOT BE SURE: THESE ARE TWO TOTALLY
> > > DIFFERENT INSTANCES.
> > >
> > >
> > > Conclusion:
> > > Unless you cache your home, create a new remote will provide you with a
> > > brand new remote target with its list re-initialized.
> > >
> > > BTW, I wanted to modify the implementation so that the target
> > list is not
> > > contained in the proxy directly but somewhere in the client in
> > a singleton
> > > object so that all proxies can share a single list (optimisation for
> > > collections for example). This may solve your problem.
> > >
> > > Cheers,
> > >
> > >
> > >
> > > Sacha

[slaboure]

For anyone thinking to have such a strange behaviour, you should try with a recent snapshot of Branch_3_2 or HEAD.

Cheers,


Sacha