EJB always clusterable in WLS6.1?

[Sioux]

Hi,
We're running a single instance Weblogic Server of version 6.1 with Stateless
Session Beans in it.
We're doing some load testing and seeing errors
e.g. (at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:220)
)
that make us think the EJBs are trying to load balance to other cluster members
(we aren't running a cluster). So to get rid of these we've tried to set the deployment
descriptor to non-clusterable.
However, it doesn't seem to work:
Here's what we had:
<stateless-clustering>
<stateless-bean-is-clusterable>true</stateless-bean-is-clusterable>
<stateless-bean-load-algorithm>round-robin</stateless-bean-load-algorithm>
</stateless-clustering>
To remove the clustering we completely removed this element, also we tried:
<stateless-clustering>
<stateless-bean-is-clusterable>false</stateless-bean-is-clusterable>
</stateless-clustering>

But each time we see this in the ejbc constructed xml files:
<cluster
clusterable="true"
replica-handler-classname="weblogic.rmi.cluster.PrimarySecondaryReplicaHandler"
>
</cluster>

<cluster
clusterable="true"
propagate-environment="true"
>
</cluster>
And get the error shown at the bottom of the email.
I reckon the way it should work is
1) It shouldn't do attempt to behave clustered anyway as we're not running a cluster
(even with the configuration set to clustered true)
2) When we remove the cluster tag or set it to false we shouldn't get any attempt
to contact cluster members.

Have I misunderstood this error or could anyone suggest what we can do to stop
these? The problem is it's REALLY slowing down our performance profiles.
Thanks
Sioux

weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Unexpected IOException
marshalling on server-side ]
at weblogic.rmi.internal.OutboundServerResponse.sendThrowable(OutboundServerResponse.java:64)
at weblogic.rmi.internal.BasicServerRef.handleThrowable(BasicServerRef.java:390)
at weblogic.rmi.internal.BasicServerRef.postInvoke(BasicServerRef.java:367)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:262)
at weblogic.rmi.internal.BasicServerRef.dispatch(BasicServerRef.java:158)
at weblogic.rmi.internal.ServerRequest.sendOneWayRaw(ServerRequest.java:92)
at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:112)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:253)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:220)
at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
at $Proxy75.validate(Unknown Source)
at com.bnye.rufus.generic.ui.UIBean.mainProcess(UIBean.java:259)
at com.bnye.rufus.generic.ui.UIBean.process(UIBean.java:74)
at com.bnye.rufus.control.web.ControlServlet.doUIBean(ControlServlet.java:336)
at com.bnye.rufus.control.web.ControlServlet.service(ControlServlet.java:103)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:263)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2390)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:1959)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

[Robert Patrick]

By default, stateless session beans and all EJB home objects are clusterable (this is not new to 6.1).
These can be safely deployed and run on a non-clustered WebLogic server instance so I do not believe that
your problem has anything to do with this. Now, if you cannot explicitly turn this off in the deployment
descriptor, that may be a bug but that is probably not the cause of your current problem.

It looks like you are trying to return something from the EJB that is not serializable. What does the
stack trace look like on the server-side (see weblogic.log)?

Hope this helps,
Robert

[sioux]

Hi Robert,
That is our weblogic.log stack trace, our Servlet and EJBS are co-located at the
moment.
One thing we're gonna try is using an ejb-local rather than remote to see if we
get rid of this but it's not a long-term solution for us.
However, you're right, the EJBs do deploy safely and run fine, and we've not got
anything going wrong when we see these errors, just lots of errors, one for every
ejb resolution. But the reason I'm accusing the clusterability is that we only
get this error after we increase the load so I get the impression the clustered
stubs are doing their damnedest to loadbalance after a certain point!!!
We've taken a more detailed look at timings now, these errors are not time-consuming,
so whatever it is isn't having a major impact on our process (40ms max, probably
less)!
Thanks for the feedback
Sioux

[Robert Patrick]

If the EJB and its client (e.g., servlet) are co-located in the same VM, the stubs will
NEVER try to load balance and will instead ALWAYS prefer the local EJB.