Getting multiple statefull session beans created

[dominic]

My application creates a stateful session bean that gets stored in the http session (or at least a handle to it does). Nothing exciting there. However, after I make a few requests to the server from my client I notice that several stateful session beans get finalized. Is this just a by-product of how JBoss handles these beans or is something funny going on? I'm suffering unbearably poor performance just now (and will likely be directed to forget about JBoss we I don't make some progress by the end of this week).

I'm using 2.4.1 (but am about to try 2.2.2 having read that it is faster...).

Cheers,

-Dominic

[hstech]

Dominic,

Can you be more specific.

- When you say "several stateful session beans get finalized", does that mean you have several stateful session beans owned by the one client?
- When they are finalized, are they first passivated (ejbPassivate)?
- By finalized, do you mean that ejbRemove is being called?
- Where are you getting the performance problems?

Cheers,

Aaron.

[dominic]

Aaron, my client only owns one stateful session bean. It looks like a new one is being created for each call I make. We've move the code from weblogic, where it correctly only created on bean for the client.

I don't believe they are passivated - the client session ends, and the http session times out. At this point our code removes the stateful session beans. Some time later the JVM garbage collects the classes as we see about six different instance of the stateful session bean being finalized (we print out their ID in the finalize method).

As for the performance problems - we're having difficulty pinning it down to an exact method, although a lot of fingers are pointing at the CacheKey.init method just now. Basically it takes about ten times as long to instantiate an entity bean in jboss as it does in weblogic. This is true of both our BMP and CMP beans. This slowdown is just too much - our client times out before the response is sent! We've used optimizeIt which points at the CacheKey constructor and I understand it does something quite inefficient at the moment because it serialises the PK (but our PKs are only integers anyway so I don't think this is the whole story).

The documentation says that it's possible to get huge inefficiencies in CMP if you're not careful - are there things there I can look at to see if we're being dumb?

Cheers,

-Dominic

[brax]

I also had the same problem with 2.4.1 and not with 2.2.2.
I'm calling Stateless session bean from a servlet :
at init() level :
// EJB
try {
System.setProperty("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");
System.setProperty("java.naming.provider.url","localhost:1099");
_bFlagEJB = true;
}

and then in the code :
/**
* appel EJB jbSql
*/
public String jbTrtSql(String iOrder , String iParam, String iUser , String iPassword ) {
String sOut = "Nok";
try {
jbSql jbS = null;
// Get a naming context
InitialContext jndiContext = new InitialContext();
// Get a reference to the Bean
Object ref = jndiContext.lookup("jb/jbSql");
// Get a reference from this to the Bean's Home interface
jbSqlHome home = (jbSqlHome) PortableRemoteObject.narrow (ref, jbSqlHome.class);
// Create an object from the Home interface
jbS = home.create();
sOut = jbS.jbSqlOrder(iOrder, iParam, iUser, iPassword ) ;
}
catch(Exception e) {
System.out.println("TrtFic1 Bean call to jbSql failed: " + e);
sOut = "Nok " + e;
}
return sOut;
}

This EJB is an SQL connection spooler. As you can see, I don't ( and don't want to ) finalyze it.

Using version 2.2.2, the EJB is loaded once;
here is its log :
[jbSql] Sql Bean Session jbSqlBean
[jbSql] Sql Bean Session Context Initialized
[jbSql] Sql Bean Session ejbCreate
[jbSql] Sql Bean Driver charge

Using version 2.4.1, the EJB is loaded for every call :
[Default] Sql Bean Session jbSqlBean
[Default] Sql Bean Session Context Initialized
[Default] Sql Bean Session ejbCreate
[Default] Sql Bean Driver charge
[Default] Sql Bean Session jbSqlBean
[Default] Sql Bean Session Context Initialized
[Default] Sql Bean Session ejbCreate
[Default] Sql Bean Driver charge
...

And here is, in the EJB, what's doing the log :
/**
Empty method body
*/
public jbSqlBean() {
System.out.println("Sql Bean Session jbSqlBean");
}
/**
Empty method body
*/
public void ejbCreate() {
System.out.println("Sql Bean Session ejbCreate");
}
/**
Empty method body
*/
public void ejbRemove() {
System.out.println("Sql Bean Session ejbRemove");
closeAllConnex( 0 );
maintenance.shutDown();
}
/**
Empty method body
*/
public void ejbActivate() {
System.out.println("Sql Bean Session ejbActivate");
}
/**
Empty method body
*/
public void ejbPassivate() {
System.out.println("Sql Bean Session ejbPassivate");
closeAllConnex( 0 );
}
/**
Empty method body
*/
public void setSessionContext(SessionContext sc) {
this.ctx = sc;
System.out.println("Sql Bean Session Context Initialized");
}


So I didn't migrated to 2.4.1 and I am wondering what's wrong

Thanks for some help.
Regards

[dominic]

I believe this is a known issue for stateless session beans (and has been fixed in the source tree). I'm specifically talking about stateful session beans, for which I am not aware of a similar issue.

-Dominic

[dominic]

Having done some more profiling I'm convinced that we have a problem with the org.jboss.ejb.CacheKey - I ran a request that took 5-6 minutes to complete. Something approaching half that time was spent in CacheKey creation...

The test was a simple loop (repeated 50 times) of looking up two entity beans. Both BMP in this case.

[dominic]

the same code runs in approximately ten seconds in weblogic...

[dominic]

OK, here's more detail than you can shake a stick at :-).

The code I'm running looks like this:

public void Test(VBSSession2 vbss2,PrintWriter out)
{
try
{
String details;
for(int i=0;i<10;i++)
{
System.out.println(i);
details = VBSRemote.remoteControl.getKindDetail (vbss2, "VBS", "Folder");
}
out.println("Done");
}
catch (Exception e)
{
System.out.println("Cock up " + e);
}
}

vbss2 is our stateful session bean. I have put debugging output in the setSessionContext, getKindDetail, ejbCreate, ejbRemove and finalize methods. The output from running this several times is:

[Default] User 'dominic' authenticated
[Default] setSessionContext
[Default] EJBCreate on VBSSession 2
[Default] setSessionContext
[Default] setSessionContext
[Default] 0
[Default]
[Default] Getting Kind Detail 3250003
[Default] Finalizing 5128410
[Default] Finalizing 241679
[Default] 1
[Default]
[Default] Getting Kind Detail 3250003
[Default] 2
[Default]
[Default] Getting Kind Detail 3250003
[Default] 3
[Default]
[Default] Getting Kind Detail 3250003
[Default] 4
[Default]
[Default] Getting Kind Detail 3250003
[Default] 5
[Default]
[Default] Getting Kind Detail 3250003
[Default] 6
[Default]
[Default] Getting Kind Detail 3250003
[Default] 7
[Default]
[Default] Getting Kind Detail 3250003
[Default] 8
[Default]
[Default] Getting Kind Detail 3250003
[Default] 9
[Default]
[Default] Getting Kind Detail 3250003
[Default] setSessionContext
[Default] setSessionContext
[Default] 0
[Default]
[Default] Getting Kind Detail 3250003
[Default] Finalizing 6371056
[Default] Finalizing 6160567
[Default] 1
[Default]
[Default] Getting Kind Detail 3250003
[Default] 2
[Default]
[Default] Getting Kind Detail 3250003
[Default] 3
[Default]
[Default] Getting Kind Detail 3250003
[Default] 4
[Default]
[Default] Getting Kind Detail 3250003
[Default] 5
[Default]
[Default] Getting Kind Detail 3250003
[Default] 6
[Default]
[Default] Getting Kind Detail 3250003
[Default] 7
[Default]
[Default] Getting Kind Detail 3250003
[Default] 8
[Default]
[Default] Getting Kind Detail 3250003
[Default] 9
[Default]
[Default] Getting Kind Detail 3250003
[Default] setSessionContext
[Default] setSessionContext
[Default] 0
[Default]
[Default] Getting Kind Detail 3250003
[Default] Finalizing 6607053
[Default] Finalizing 4738155
[Default] 1
[Default]
[Default] Getting Kind Detail 3250003
[Default] 2
.
.
.


As you can see, the ID at the end of each Kind Detail line is the same - so it's using the same session bean to execute each method call. However, each time the Test method is invoked from the client we have two session beans whose setSessionContext method is called and two session beans whose finalize method is called.

I also discovered that part of the performance problem was because I stil had the profiler plugin running (big performance hit even if you're not recording...). The performance is still unacceptably poor but not as bad as it was!

Any suggestions greatfully received..

-Dominic