AW: Calibrating EJB Pooling in Orion
Title: Hi Falk,See my comments below! Regards, Tibor Hegyiwebmiles AGRidlerstr. 31b80339 MünchenTel. 089/ 12469-461Fax 089/ 12469 - 222e-mail: [EMAIL PROTECTED]-Ursprüngliche Nachricht-Von: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]]Im Auftrag von FalkLanghammerGesendet: Donnerstag, 8. März 2001 19:43An: Orion-InterestBetreff: Re: Calibrating EJB Pooling in OrionHi Tibor,I may have no answers but volunteer to discuss the issue with You...- Original Message -From: Tibor HegyiMy test application scenario is: servlet-SLSB-SFSB-Entity. (A - B:means A instantiates B and calls business methods on it)1. When the SLSB bean looks up the home interface of SFSB, the SFSB'sejbActivate is called a few dozens times. Why? Does Orion create pre-pooledinstances of Stateful session beans (before they have been createdexplicitely)? Strange. The same number of ejbPassivate-calls are performedwhen I shut down the server.No. ejbActivate() is called when a bean needs to be in ready state. Onepossible explaination could be that Orion persists SFSB so that they survivea server restart. This is an option in the spec which Orion chooses toimplement. Fine so far.[TH] I see the point of ejbActivate(), but why does Orion put hundreds of instances in the SFSB ready pool before I used one of them. Furthermore, why the number of these SFSBs are increasing? Let me give you a bit more detail. My SLSB calls create() on SFSB's home interface everytime it wants to call a method on the SFSB. This should be ok, since SBs cannot be identified. In test 1 I performed these steps 100 times. In test 2 I did it 120 times. So the number of "dummy" SFSBs preloaded in the ready state got up to 120. How can I decrease or change this number? Anyway, calling ejbActivate on a SFSB before calling setSessionContext and ejbCreate is somehow violates rules of the lifecycle diagram in chapter 6.6 of the EJB 1.1. spec that says ejbActivate is called when SFSB isactivated from the passive state. OK, I'd accept that this is due to Orion's featureof persisting instances ofSFSB (where is it in the spec?), but the number of such instances may be huge at the end. Something looks dangerous: You create a SFSB from a SLSB. I would presumethat each time you instantiate the SFSB you create a new instance - even ifyou are in the same session!! The correct way (IMHO) is to instantiate aSFSB from a servlet of session scope and store its reference in its sessioncontext. As always, I may be wrong.[TH] My scenario might not be nice, but why is it dangerous? In the sense, that too many SFSBs are created? Well calling remove() on the SFSB would solve the problem of multiple instances. Anyway the container should passivate the SFSBs and after the timeout period remove them. But do you think that the Orion cannot passivate SFSBs while in the Web session is alive? I mean while I keep calling the servlet again and again that calls SLSBs that create and call SFSBs. I might miss and do something wrong. 2. What does the number of this kind of pre-pooled beans depend on?Strange. I changed the timeout value in orion-eib.jar from 1800 sec to 10sec but Orion behaves the same way. Strange.The SFSB should go away (return to pooled state calling ejbPassivate())after the session expires. [TH] Why the SFSBs cannot be passivated when not referred to anymore? I mean after the method of the SLSB has executed, the SFSB created in this method should be subject to passivation. But Orion does not seem doing this. Or it does but behind the scenes.Entity beans:I set up max-instances and validity-timeout attributes in orion-ejb.jar.Despite this:1. When issuing a findAll (or any multiple result findXXX method) methodcall on the Entity Home the number of instances may exceed the max-instancessetting. Hence the number of entity instances can increase endlesslypotentially causing an out-of-memory problem. Strange.Are you sure?Normally, EB are reused from one business method to another. Maybe, Youtouch *all* members of the collection returned from the finder within asingle transaction? [TH] The scenario is: servlet calls the finder on the home of EB that returns a collection of the EBs. Orion createsEB instances for the result set. I do not go through the collection and call any methodon the EBs at all. Although, it is nota good programming practice toquery hundreds or thousandsof EBs using finder methods but rather calling findByPrimaryKey on the ones really needed.2. After the validity-timeout has elapsed AND the number of max-instanceswas exceeded AND a new instance is being created, the non-valid (overvalidity-timeout) ones are removed from the pool.Looks ok, because you are between two business methods. The max-instancesetting can only become effective when a new instance is needed AND there*are* any idle EBs (when a new one is created the server needs to decidewether to passivate an existing EB or to cr
Calibrating EJB Pooling in Orion
Hi, Well, I am a bit confused how Orion handles pools of Entity/SLSB/SFSB instances. Let me share my expreiences so that you can give me some explanation and clue how to calibrate pooling in Orion. Thiscan be important intimes of heavy load applications running in Orion. I have already browsed through the archives but most of the entries deal with Database connection pooling or Entity pooling. My test application scenario is: servlet-SLSB-SFSB-Entity. (A - B: means A instantiates B and calls business methods on it) My questions: Statful beans: 1. When the SLSB bean looks up the home interface of SFSB, the SFSB's ejbActivate is called a few dozens times. Why? Does Orion create pre-pooled instances of Stateful session beans (before they have been created explicitely)? Strange. The same number of ejbPassivate-calls are performed when I shut down the server. 2. What does the number of this kind of pre-pooled beans depend on? Strange. Ichanged the timeout value in orion-eib.jar from 1800 sec to 10 sec but Orion behaves the same way. Strange. It seems to me that Orion somehow remembers the maximum number of usage of a SFSB and next time after orion is RESTARTED it creates the same number of pseudo-instances as I described above. Could this be the case? Stateless beans: they seem to work fine. Entity beans: I set up max-instances and validity-timeout attributes in orion-ejb.jar. Despite this: 1. When issuing a findAll (or any multiple result findXXX method)method call on the Entity Home the number of instances may exceed the max-instances setting. Hence the number of entity instances can increase endlesslypotentially causing an out-of-memory problem. Strange. 2. After the validity-timeout has elapsedAND the number of max-instanceswas exceededAND a new instance is being created, the non-valid (over validity-timeout) ones are removed from the pool. So that's it. If anyone could give us (some might also be interested in this topic) explanation or share his/her expreiences I would appreciate very much. Tibor Hegyiwebmiles AGRidlerstr. 31b80339 MünchenTel. 089/ 12469-461Fax 089/ 12469 - 222e-mail: [EMAIL PROTECTED]
Re: Calibrating EJB Pooling in Orion
Hi again, - Original Message - From: Tibor Hegyi Furthermore, despite the overtime Entity instances are removed from the instance pool, the amount of memory does not reduce at all!. Quite strange and bad news (if true) to those of many complaining about memory problems. At least according to WinNT's Task-manager. Can anybody confirm this? Well, isn't this the default behaviour of the Java VM? I have seen that option '-incGC' (or similiar) can lead to memory returned to the OS but speed is sacrified somewhat. Falk
Re: Calibrating EJB Pooling in Orion
Hi Tibor, I may have no answers but volunteer to discuss the issue with You... - Original Message - From: Tibor Hegyi My test application scenario is: servlet-SLSB-SFSB-Entity. (A - B: means A instantiates B and calls business methods on it) 1. When the SLSB bean looks up the home interface of SFSB, the SFSB's ejbActivate is called a few dozens times. Why? Does Orion create pre-pooled instances of Stateful session beans (before they have been created explicitely)? Strange. The same number of ejbPassivate-calls are performed when I shut down the server. No. ejbActivate() is called when a bean needs to be in ready state. One possible explaination could be that Orion persists SFSB so that they survive a server restart. This is an option in the spec which Orion chooses to implement. Fine so far. Something looks dangerous: You create a SFSB from a SLSB. I would presume that each time you instantiate the SFSB you create a new instance - even if you are in the same session!! The correct way (IMHO) is to instantiate a SFSB from a servlet of session scope and store its reference in its session context. As always, I may be wrong. 2. What does the number of this kind of pre-pooled beans depend on? Strange. I changed the timeout value in orion-eib.jar from 1800 sec to 10 sec but Orion behaves the same way. Strange. The SFSB should go away (return to pooled state calling ejbPassivate()) after the session expires. It seems to me that Orion somehow remembers the maximum number of usage of a SFSB and next time after orion is RESTARTED it creates the same number of pseudo-instances as I described above. Could this be the case? No. cf. my text above. Entity beans: I set up max-instances and validity-timeout attributes in orion-ejb.jar. Despite this: 1. When issuing a findAll (or any multiple result findXXX method) method call on the Entity Home the number of instances may exceed the max-instances setting. Hence the number of entity instances can increase endlessly potentially causing an out-of-memory problem. Strange. Are you sure? Normally, EB are reused from one business method to another. Maybe, You touch *all* members of the collection returned from the finder within a single transaction? BTW, if two business methods overlap in time, an EB may exist in multiple instances even for the same primary key! When recursions occur you need to start to think about proper EB deployment settings. Orion has a flag wether to preload EBs on a finders. The flag defaults to true. Maybe, you need to set it to false? Anyway, the max-instance setting may only affect EBs not currently in a business method. 2. After the validity-timeout has elapsed AND the number of max-instances was exceeded AND a new instance is being created, the non-valid (over validity-timeout) ones are removed from the pool. Looks ok, because you are between two business methods. The max-instance setting can only become effective when a new instance is needed AND there *are* any idle EBs (when a new one is created the server needs to decide wether to passivate an existing EB or to create a new one. Why should the server ever touch an EB outside this decision making?). So that's it. If anyone could give us (some might also be interested in this topic) explanation or share his/her expreiences I would appreciate very much. Tibor Hegyi Falk -- Dr. Falk Langhammer Living Pages Research GmbH Holzstr. 19 D-80469 Munich, Germany mailto:[EMAIL PROTECTED] http://www.living-pages.de Phone +49 (89) 260 255 32Fax +49 (89) 260 255 35
