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(EntityContainer.ja
va:494)
at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchron
izationInterceptor.java:147)
at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterce
ptor.java:77)
at
org.jboss.ejb.plugins.TxInterceptor.invokeHome(TxInterceptor.java:84)
at
org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.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]
