I have some (hopefully) quick clarification questions to complete my mental model of how the collocation optimization works. I'm still a little fuzzy after looking in here and in the docs. Especially w.r.t. 10.3.5+ and 12c:
If this is covered in a document, blog page, etc., that I have not found, I'd appreciate a reference.
1. By default the semantics used are call-by-value. When you deploy an EJB WebLogic will issue a warning, saying that you can enable-call-by-reference. This can be accomplished by using the weblogic-ejb-jar.xml deployment descriptor (weblogic-ejb-jar.xml Deployment Descriptor Reference - 11g Release 1 (10.3.6)).
Some general information on configuring enterprise beans can be found here: Middleware Snippets: Configuring Enterprise Beans in WebLogic.
2. You are probably referring to message-driven-bean here (as you are using the terms consumer and producer). WebLogic creates a pool of message-driven-bean instances (default is 16) that are listening to the (configured) destination. You can choose the type of destination (stand-alone or distributed) if you want fail-over. When using a distributed destination (that is deployed to a number of JMS Server) the producer gets connected to an instance, the same goes for a consumer instance (see here for more information including some pictures - 9 Using Distributed Destinations).
An example set-up can be found here: Middleware Snippets: JMS Migration in WebLogic Server 12c.
3. You can see the thread behavior when using the Admin Console, click deployments, monitoring tab, workload tab (here you can see which server is doing the work, keep an eye on the completed requests). Some tuning tips with respect to message-driven-beans can be found here: Tuning Message-Driven Beans - 11g Release 1 (10.3.6), and JMS: Tuning WebLogic JMS - 11g Release 1 (10.3.6).
More on monitoring JMS can be found here: Monitoring JMS Statistics and Managing Messages - 11g Release 1 (10.3.6). Some general information on JMS can be found here: Middleware Snippets: Messaging in WebLogic Server: Best Practices.
Thank you for your answers. However, it looks like I may have not been clear on what I was looking for.
on (2), I am talking about (in my case) SLSB client stub failover among the SLSB provider instances. If the local copy of the SLSB in the same cluster member as the client is not available, will the client stub failover to using rmi over the network to another cluster member - or will the SLSB method invocation fail?
on (3) - also not MDBs. I am wondering about whether if SLSB is in one app on a server, and the client is in another app on the same server, whether two threads are in play (client and server), or only one - i.e., client's thread used in the SLSB service execution, or whether there's a context swap to another thread from the WebLogic thread pool
WebLogic creates a pool of stateless bean instances (on each server in the cluster), such that a client request can be handled immediately. By default to pool start empty and grows on demand. (more on EJB pooling can be found here: Middleware Snippets: Configuring Enterprise Beans in WebLogic).
When the client is loaded by the same class-loader (i.e., the client located in the same .ear) the calls to the instance can be done by call-by-reference (but you have to configure this the default will be call by value).
When the server fails (in-flight) you can tell WebLogic to migrate the transaction that was running (more on handling failures can be found here: Middleware Snippets: Managing Failure Conditions in a WebLogic Environment).
Also when the client is loaded by the same class-loader, the same thread is used (see also here for a graphic example Middleware Snippets: Deploy WebLogic 12c to Multiple Machines). At the end of the post you see that the call to the servlet, EJB invocation by the servlet and execution of the JDBC statement are handled by the same execute thread