Returning from a Session Bean remote methods takes a long ti

[nbirch]

Hi,

I'm measuring the time taken for a simple loop that calls a Session Bean remote method. In this method its calls an EntityBean. ~70% of the total loop time is spend just returning from the Session Bean remote method (~100 -> 300ms)! There is no application code being executed, its just the return.

The Session Bean remote method in question has its
transaction attribute set to RequiresNew, and the
Entity Bean being updated has its CMP commit option set to "A".

Everything is on the same machine.

What is taking so long?


My configuration is:
JBoss 3.0.2, EJB 1.1 CMP
Linux RH7.3
Pentium III, 500MHz
JBoss heap: min:32M max:256M

Thanks
NBirch

[jonlee]

Just want to be sure of the facts.

1) Is that time measured from the client side or within your session bean?
3) If it is the time measured from within your bean, does that mean that 30% of the time is spent with the entity bean operation?

If you could clarify what the time breakdowns are, it would be easier to visualise.

I guess if we could understand:
1) The time at the beginning of the iteration of the loop
1) The time lapse to get the home and remote interfaces (from the client side)
2) The time the method is reached (from inside the bean)
3) The time taken to execute the CMP call (from inside the bean)
4) The time the method completed (from inside the bean)
5) The time the method call completed (from the client side)
6) What interface/address you are using to call the bean

That would give us some idea of where the time is being spent within the salient regions of the overall call and whether there are network issues at play.

[nbirch]

Thanks for your relpy. I'll post more details, but here is a quick clarification:

I have a separate process (with its own main) that calls SB1 in JBoss. SB1 calls SB2, and SB2 calls EB1 to update its attributes.

This constitutes the loop I'm timing. I have been timing by recording timestamps at points of interest and then printing them at the end of the loop.

A common loop time is 170ms. The time difference between the last brace of the SB2 remote method and the point at which the SB2 remote method has returned in SB1 is 127ms.

Since SB1 and SB2 are within JBoss (the same process) I thought that RMI was not used, even though I'm using EJB1.1.

I'll post more details, but hopefully this is more clear.

Thanks!
NBirch

[jonlee]

Thanks for clarifying. It wasn't clear that the client from which you were calling was within the container. It makes sense now as to why you spec'd the new transaction explicitly.

The theory is that RMI shouldn't be used as long as the naming.provider.URL is not defined. You'll probably want to check it but even so, 127 ms is quite a time lag.

Sounds like something is blocking the return. What happens if SB1 is the start of the transaction chain and SB2 does not create a new transaction? Just wondering whether EB1 is halting progress as SB2 is effectively the controller on this transaction chain and won't return until everything safely completes. In which case, you can look at the delay effect of EB1. Or try uncoupling EB1 for test purposes.

Just thinking out aloud here.

[nbirch]

Thanks for the suggestions.

In jndi.properties the naming.provider.URL is commented out so I'm assuming its not over RMI.

I'll try playing with the transactions. It makes sense that SB2 would not actually return until the transaction was safely completed. So is there some code in the Session Bean parent class that does a sleep/wait until the transaction manager says its done?

If this is the case I guess I'll have to live with this delay....or mabe upgrade to JBoss3.2 to see if that is faser.

Thanks again,
NBirch

[nbirch]

Hi,

I removed the EB1 call from SB2 and now the SB2 remote method call returns in 1ms. So since the SB method uses RequiresNew it cannot return until the transaction is complete. This does make sense.

So now I'm wondering how I can speed up the transaction! Different transaction manager? Newer version of JBoss, Different Database?

What do you think? I will probably post this as a general question to the Datasource discussion group too.

Thanks again,
NBirch

[jonlee]

You can try a new transaction manager. However, I'd first have a look for a reason in the database side of things. That is most likely the source - EB1 must be trying to commit the data it is holding and it is taking a while to do that. You can turn on debug in your logs and see a bit more detail on the EB operations. You could also simulate EB1 by building a stateless session bean that performs the same data operations and measure the performance. You can also experiment by changing the commit plan for the CMP container - you could view the effects of 'B' and 'C'.