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