Do you have overloaded creates? more than one?
if so it is our friend showing its ugly head again, I thought I had wacked
it...

marc


> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Antman
> Sent: Monday, June 19, 2000 9:47 AM
> To: jBoss
> Subject: Re: [jBoss-User] Jboss benchmark
>
>
> On Mon, 19 Jun 2000, Rickard �berg wrote:
>
> > Hi!
> >
> > Peter Antman wrote:
> > >
> > > On 19 Jun, Aaron Mulder wrote:
> > > >       The first problem below (no transaction manager in JNDI) is
> > > > probably because you haven't loaded Rickard's new
> Transaction service in
> > > > your jboss.conf before the JDBC pool entry.  The entry
> should look like:
> > > >
> > > > <MLET CODE="org.jboss.tm.TransactionManagerService"
> ARCHIVE="jboss.jar"
> > > > CODEBASE="../lib/ext">
> > > > </MLET>
> > >
> > > But I do have that:
> > >
> > > <MLET CODE = "org.jboss.tm.TransactionManagerService"
> ARCHIVE="jboss.jar,jta-spec1_0_1.jar" CODEBASE="../lib/ext/">
> > > </MLET>
> > >
> > > <MLET CODE = "org.jboss.jdbc.XADataSourceLoader"
> ARCHIVE="jboss.jar,minerva.jar" CODEBASE="../lib/ext/">
> > >    <ARG TYPE="java.lang.String" VALUE="ejbPool">
> > >    <ARG TYPE="java.lang.String"
> VALUE="org.jboss.minerva.xa.XADataSourceImpl">
> > >    <ARG TYPE="java.lang.String"
> VALUE="jdbc:postgresql://localhost/news">
> > >    <ARG TYPE="java.lang.String" VALUE="pra">
> > >    <ARG TYPE="java.lang.String" VALUE="hej">
> > >    <ARG TYPE="java.lang.String" VALUE="">
> > >    <ARG TYPE="java.lang.Integer" VALUE="2">
> > >    <ARG TYPE="java.lang.Integer" VALUE="5">
> > >    <ARG TYPE="java.lang.String"
> VALUE="GCEnabled=true;ShrinkingEnabled=true">
> > > </MLET>
> > >
> > > Right now basicly nothing works any longer, and I don't have
> time to try
> > > to fix it my self right now. This means that Percolator support for
> > > Jboss is broken, wich I think is sad. But I can't figure out how to
> > > solve this in a quick way.
> >
> > As I said before, the XADSL needs to be fixed by Aaron to conform to the
> > new startup process (and he's on it). Until that is fixed you have to
> > use the old DataSourceImpl which is included in the jboss.conf file in
> > CVS.
>
>
> Yes I know, and - as I said in a previous mail - the that does not work
> either. I get an invokation error on home - and have not been able to
> trace it to a known problem (I had problem with the hash bug before, and
> problem whn the classses was loaded from different builds, making the
> enhertitance chain fuck up, but this does not seem to be the case now).
> Here is the first part of the stack trace:
>
>
> [ArticleManager] java.lang.IllegalArgumentException: argument type
> mismatch
> [ArticleManager] java.lang.IllegalArgumentException: argument type
> mismatch
> [Default] In invoke Home interface
> org.backsource.borea.news.data.interfaces.ArticleManagerHomecreate0
> [ArticleManager] In invoke Home interface
> org.backsource.borea.news.data.generated.ArticleEntitySuperHomecreate1
> [ArticleEntity] InvokingHome create
> [ArticleEntity] org.backsource.borea.news.data.shared.ArticleVH@199939
>         at java.lang.reflect.Method.invoke(Native Method)
>         at
> org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(Enti
> tyContainer.ja
> va:494)
>         at
> org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(
> EntitySynchron
> izationInterceptor.java:147)
>         at
> org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityI
> nstanceInterce
> ptor.java:77)
>         at
> org.jboss.ejb.plugins.TxInterceptor.invokeHome(TxInterceptor.java:84)
>         at
> org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInter
> ceptor.java:75
> )
>         at
> org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:101)
>         at
> org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:306)
>         at
> org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invokeHome(
> JRMPContainerI
> nvoker.java:169)
>         at
> org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invokeHome(
> JRMPContainerI
> nvoker.java:136)
> [...]
>
> /Peter
>
>  > > /Rickard > >
> > >
> > > /Peter
> > > >
> > > >       The second error below (pool name not bound) is caused by the
> > > > first.  Since the connection pools must register with the
> > > > TransactionManager, they don't work if the
> TransactionManager isn't bound.
> > > > This should go away once you fix the first problem.
> > > >
> > > > Aaron
> > > >
> > > > On Mon, 19 Jun 2000, Peter Antman wrote:
> > > >> Hi, I checked outv the latest version, and after fixing a
> lot of merge
> > > >> conflicts I started it, and it no longer works. Is there
> any important
> > > >> (documented/undocumented) changes that hace occured since javaOne).
> > > >>
> > > >> Here are my problems:
> > > >>
> > > >>  java.lang.IllegalStateException: There is no TransactionManager in
> > > >>  JNDI!
> > > >>         at
> org.jboss.jdbc.XADataSourceLoader.<init>(XADataSourceLoader.java:48)
> > > >>         at java.lang.reflect.Constructor.newInstance(Native Method)
> > > >>         at
> javax.management.MBeanServer.internal_instantiate(MBeanServer.java:2204)
> > > >>         at
> javax.management.MBeanServer.createMBean(MBeanServer.java:717)
> > > >>         at
> javax.management.loading.MLet.getMBeansFromURL(MLet.java:385)
> > > >>         at
> javax.management.loading.MLet.getMBeansFromURL(MLet.java:208)
> > > >>         at org.jboss.Main.<init>(Main.java:111)
> > > >>         at org.jboss.Main.<init>(Main.java:86)
> > > >>         at org.jboss.Main$1.run(Main.java:76)
> > > >>         at
> java.security.AccessController.doPrivileged(Native Method)
> > > >>         at org.jboss.Main.main(Main.java:67)
> > > >>
> > > >> Hm, never seen before.
> > > >>
> > > >>  [Container factory] javax.naming.NameNotFoundException:
> xa.ejbPool not
> > > >>  bound
> > > >>
> > > >> In the docukmentation for minerva, this was stated to be
> the name that
> > > >> should be mapped if I have an entry like this:
> > > >>
> > > >>
> > > >> <MLET CODE = "org.jboss.jdbc.XADataSourceLoader"
> ARCHIVE="jboss.jar,minerva.jar" CODEBASE="../lib/ext/">
> > > >>    <ARG TYPE="java.lang.String" VALUE="ejbPool">
> > > >>    <ARG TYPE="java.lang.String"
> VALUE="org.jboss.minerva.xa.XADataSourceImpl">
> > > >>    <ARG TYPE="java.lang.String"
> VALUE="jdbc:postgresql://localhost/news">
> > > >>    <ARG TYPE="java.lang.String" VALUE="pra">
> > > >>    <ARG TYPE="java.lang.String" VALUE="none">
> > > >>    <ARG TYPE="java.lang.String" VALUE="">
> > > >>    <ARG TYPE="java.lang.Integer" VALUE="2">
> > > >>    <ARG TYPE="java.lang.Integer" VALUE="5">
> > > >>    <ARG TYPE="java.lang.String"
> VALUE="GCEnabled=true;ShrinkingEnabled=true">
> > > >> </MLET>
> > > >>
> > > >> And then it ends with:
> > > >>
> > > >>  [JMX RMI Adaptor] Starting
> > > >> [JMX RMI Adaptor] Started
> > > >>         at org.jboss.Main.<init>(Main.java:152)
> > > >>         at org.jboss.Main.<init>(Main.java:86)
> > > >>         at org.jboss.Main$1.run(Main.java:76)
> > > >>         at
> java.security.AccessController.doPrivileged(Native Method)
> > > >>         at org.jboss.Main.main(Main.java:67)
> > > >> [Default] java.lang.ClassCastException:
> javax.management.RuntimeMBeanException
> > > >>
> > > >> This was not to fun I have to say.
> > > >>
> > > >>
> > > >>
> > > >> >
> > > >> > Then there's the following issues (that I know of):
> > > >> > * The JNDI implementation used to be slow if you included new
> > > >> > InitialContext() in your code since no caching was done.
> This has been
> > > >> > changed so that the server connection is cached, and the
> VM-local case
> > > >> > is also optimized now.
> > > >> >
> > > >> > * Do you look up the home each time? That is an
> additional performance
> > > >> > hit.
> > > >>
> > > >> Yes I do. Which is basicly what you would have to do in a web
> > > >> environement.
> > > >>
> > > >> >
> > > >> > * The strangest thing is that returning a EJBObject is
> extremely slow.
> > > >> > Right now I have a call that takes an EJBObject and
> returns it, which
> > > >> > takes 15 ms to invoke. The same method with a String
> takes 3 ms. One
> > > >> > thing I found was that RM I was doing DGC calls when the
> EJBObject
> > > >> > entered the VM, but it didn't reuse connections to the
> server. This was
> > > >> > not only a performance hit, but also led to OutOfMemory
> exceptions. So
> > > >> > something is going on which is making it very slow. One
> optimization I
> > > >> > have found is to turn off the security manager, which
> speeds things up
> > > >> > significantly. I will add this as a configuration option.
> > > >> >
> > > >> > * Many of the Entity plugins (caching mainly) are not
> yet optimized.
> > > >> >
> > > >> > I am glad that you are doing performance benchmarks, and
> while your
> > > >> > numbers are a bit extreme I think I can account for most of the
> > > >> > problems. Could you please send me the code and I can do
> some testing
> > > >> > here? This would help enourmously in locating issues.
> > > >>
> > > >> Yes I will pack it later, but it is based on Percolator,
> so you will
> > > >> probably need to use Percolator if you are interested in
> rebuilding.
> > > >>
> > > >> Regards
> > > >> Peter
> > > >>
> > > >> >
> > > >> > regards,
> > > >> >   Rickard
> > > >> >
> > > >> >>
> > > >> >> Here it comes:
> > > >> >>
> > > >> >> I did a small timing on a bean developed with Percolator
> > > >> >> (http://www.percolator.org) on three different EJB
> servers: jboss, jonas
> > > >> >> and Weblogic 5.1. It is a rather small entity bean and
> the test was done
> > > >> >> from one client only. First it creates 1000 entitys,
> then it looks up each
> > > >> >> entity (in percolator mening getting all the data over
> in a value holder),
> > > >> >> then it just lookes up the same entity 1000 times.
> > > >> >>
> > > >> >> The result? For weblogic this took about 50ms for each
> operation. Creating
> > > >> >> a bean took 50ms, looking it up 49ms. With jonas, this
> took about 2-3
> > > >> >> times longer. (184ms to create, 169ms to look up each
> and 128ms to lookup
> > > >> >> one several times). But with jboss, this took a lot
> longer. It took about
> > > >> >> 15 times longer to create a bean compared to WLS5.1,
> and about 7-8 times
> > > >> >> longer to lookup a bean.
> > > >> >>
> > > >> >> I have to admit, they was not even run on the same JVM,
> WLS was Sun 1.2.2
> > > >> >> for Linux and Jonas 1.3 for Linux (and I could not find
> a way to turn of
> > > >> >> all the logging in jboss), but it still sees to be a to
> huge different to
> > > >> >> really be only about runtime differenses, or am I
> wrong? Is there a way to
> > > >> >> speed up jboss? Or is this low performance a known problem?
> > > >> >>
> > > >> >> Hope you don't take me wrong. I would really like to
> see jboss beeing one
> > > >> >> of the performance leader (it will make it a lot easier
> to recommend it
> > > >> >> then).
> > > >> >>
> > > >> >> Greetings
> > > >> >> Peter
> > > >> >>
> > > >> >> Oh, here are the numbers:
> > > >> >>
> > > >> >> (In millis)
> > > >> >> Create 1000 Articles    Find 1000 Articles      Lookup
> 1 article 1000
> > > >> >> times
> > > >> >> Jonas  184553 (184)     169045 (169)            128174 (128)
> > > >> >> WLS    49886 (50)       48867                   56429
> > > >> >> jboss  733522 (733)     373391 (373)            379657 (379)
> > > >> >>
> > > --
> > > ------------------------------------------------------------
> > > Peter Antman             Technology in Media, Box 34105 100
> 26 Stockholm
> > > Systems Architect        WWW: http://www.tim.se
> > > Email: [EMAIL PROTECTED]  WWW: http://www.backsource.org
> > > Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
> > > ------------------------------------------------------------
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe:        [EMAIL PROTECTED]
> > > To unsubscribe:      [EMAIL PROTECTED]
> > > Problems?:           [EMAIL PROTECTED]
> >
> > --
> > Rickard �berg
> >
> > @home: +46 13 177937
> > Email: [EMAIL PROTECTED]
> > http://www.telkel.com
> > http://www.jboss.org
> > http://www.dreambean.com
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe:        [EMAIL PROTECTED]
> > To unsubscribe:      [EMAIL PROTECTED]
> > Problems?:           [EMAIL PROTECTED]
> >
>
> ------------------------------------------------------------
> Peter Antman           Technology in Media, Box 34105 100 26 Stockholm
> Systems Architect      WWW: http://www.tim.se
> Email: [EMAIL PROTECTED]        WWW: http://www.backsource.org
> Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
> ------------------------------------------------------------
>
>
>
> --
> --------------------------------------------------------------
> To subscribe:        [EMAIL PROTECTED]
> To unsubscribe:      [EMAIL PROTECTED]
> Problems?:           [EMAIL PROTECTED]
>
>



--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Problems?:           [EMAIL PROTECTED]

Reply via email to