Who is Scott ? And where do I find his answer? Actually I'm looking forward to hear from you (or others that could help) about: Wither there a way to turn this current (extended) concurrent JBoss handling off, and rather allow additional requests (to the available instances within a pool) to wait until (freed) bean instances are returned back to the pool..? Or is the only way for me to currently address it if via modifying the org.jboss.ejb.plugins.AbstractInstancePool.get() method that you have outlined below. If so, is there other methods that I should also be modifying, in order to insure that all bean's container types are behaving the same?
Jeff. PS: Do you think that I should post this in the to-do list for future JBoss releases (if it exists)? >From: "Sacha Labourey" <[EMAIL PROTECTED]> >To: "jeff andrews" <[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?! >Date: Fri, 28 Dec 2001 10:38:45 +0100 > >So I guess you have your (good) answer from Scott ;) > > > -----Message d'origine----- > > De : jeff andrews [mailto:[EMAIL PROTECTED]] > > Envoyé : jeudi, 27 décembre 2001 20:41 > > À : [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Objet : RE: [JBoss-dev] JBOSS EJB Container Bug ?! > > > > > > Hi Sacha; > > > > Thanks allot for the insightful reply. It was the answer that I > > long waited > > for. > > > > Given what you stated/explained: > > "JBoss has a goal: to serve each request immediately. > > Consequently, if the > > pool is empty, a new instance is created and, once the instance > > is returned > > to the pool, the instance will be freed (and not returned back to > > the pool). > > Thus, JBoss don't wait for an instance to become available to serve > > concurrent requests." > > > > J2EE Applications that are deployed on JBoss will not be able to > > guarantee a > > specific performance at all times. In other-words; if I'm selling a J2EE > > application product/solution that is deployed on JBoss within a client's > > server machine, and the client requires that there would always be a > > guaranteed performance (i.e. throughput) for each requesting/connecting > > client to a particular ejb (bean) resource. JBoss goal stated > > above, would > > take away the chance of me offering a solution/product application that > > would optimally run, and meet the required performance on a particular > > machine (available) resources, that could be stated as part of the > > product's/solution's installation minimum requirements. > > > > With this king of JBoss flexibility that you have stated, it's > > true that you > > would accommodate all requesting (concurrent) clients, but this > > would be on > > the expense of the overall performance that one would like to insure as >a > > minimum. > > > > I realize that even in the J2EE spec. for v1.2 or v1.3 (Section 5.4.3) >it > > was not clearly required/specified how container (available > > instance bean) > > pool resources should be managed/handled. However, since many of > > the other > > J2EE vendor products that I have tried (i.e. WLS, iPlanet, > > Borland) operates > > on this kind of performance configurational guarantee, where concurrent > > clients will have to wait until available bean instance resources > > (that have > > been configured with) are available, in order to reuse them > > (where it can't > > share). > > > > And since I'm really more interested in the use of JBoss for promoting > > deployment of our application's solutions on it for our clients (for > > obviouse reasons, especially cost and ease of use), is there a > > way to turn > > this current (extended) concurrent JBoss handling off, and rather allow > > additional requests (to the available instances within a pool) to > > wait until > > (freed) bean instances are returned back to the pool..? > > Or is the only way for me to currently address it if via modifying the > > org.jboss.ejb.plugins.AbstractInstancePool.get() method that you have > > outlined below. If so, is there other methods that I should also be > > modifying, in order to insure that all bean's container types are > > behaving > > the same? > > > > Appreciate very much your thoughts and feedbacks. Thanks allot in >advance. > > > > Regards; > > Jeff. > > > > > > > > > > >From: "Sacha Labourey" <[EMAIL PROTECTED]> > > >To: "jeff andrews" <[EMAIL PROTECTED]>, > > ><[EMAIL PROTECTED]> > > >Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?! > > >Date: Thu, 27 Dec 2001 17:56:03 +0100 > > > > > >Hello Jeff, > > > > > >For you problem, take a look at > > >org.jboss.ejb.plugins.AbstractInstancePool.get(): > > > > > > public synchronized EnterpriseContext get() > > > throws Exception > > > { > > > //DEBUG Logger.debug("Get instance "+this); > > > > > > if (!pool.empty()) > > > { > > > mReadyBean.remove(); > > > return (EnterpriseContext)pool.pop(); > > > } else > > > { > > > try > > > { > > > return create(container.createBeanClassInstance()); > > > } catch (InstantiationException e) > > > { > > > throw new ServerException("Could not instantiate >bean", > > >e); > > > } catch (IllegalAccessException e) > > > { > > > throw new ServerException("Could not instantiate >bean", > > >e); > > > } > > > } > > > } > > > > > > > > >As you can see, with this implementation, JBoss has a goal: to serve >each > > >request immediately. Consequently, if the pool is empty, a new > > instance is > > >created and, once the instance is returned to the pool, the > > instance will > > >be > > >freed (and not returned back to the pool). Thus, JBoss don't wait for >an > > >instance to become available to serve concurrent requests. > > > > > > => the pool size will never exceed the size you indicate in your > > >deployment > > >descriptor *but* the number of active instances *may* be bigger if > > >concurrent acccess require it. > > > > > > > What am I messing ?!! Please help.... As I have bean > > > > struggling with this kind of a problem for over a month > > > > now. > > > > > >And in 10 seconds of JBoss consulting you have your answer ;) > > > > > >Cheers, > > > > > > > > > > > > Sacha > > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp. > > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
