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>
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]
> >
>
> --
> ------------------------------------------------------------
> 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]
