Re: JDBC connection pool memory leak
Update: Confirmed, everything looks good after running 46 hours. I also started a second test yesterday using the same code but Eclipselink instead of OpenJPA. It too looks good after 24 hours. The only instances I could see increasing slowly were objects called "compiledICHolderKlass", which I think are associated with the inline cache of the Hotspot compiler. After some time these instances stopped increasing, as expected. -- Bjorn Danielsson Cuspy Code AB "Howard W. Smith, Jr." wrote: > Well, I thank you both. After this discussion and fix, I just had to > download the latest SNAPSHOT of TomEE plus (even though I am using embedded > Derby), and web app seems a bit faster 'tonight'. :) > > > On Sun, Jan 6, 2013 at 10:19 AM, Bjorn Danielsson < > bjorn-apa...@lists.cuspycode.com> wrote: > >> Many thanks Romain!
Re: JDBC connection pool memory leak
Many thanks Romain! It looks like the memory leak is gone with the new snapshot. The extra Mysql Statement and ResultSet instances disappeared even without configuring JdbcInterceptors = StatementFinalizer. But I enabled StatementFinalizer for a longer test. I'll leave it running for a few days just to confirm that the leak is completely plugged. -- Bjorn Danielsson Cuspy Code AB Romain Manni-Bucau wrote: > ok, > > with https://issues.apache.org/jira/browse/TOMEE-703 (available > tomorrow on snapshot) > > + > > > DataSourceCreator tomcat > JdbcDriver com.mysql.jdbc.Driver > JdbcUrl jdbc:mysql://localhost:3306/poolbugtest > ValidationQuery SELECT * FROM MYTABLE > JtaManaged true > jdbcInterceptors = StatementFinalizer > > > it should be better > > can you check it please? > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2013/1/4 Howard W. Smith, Jr. : >> Is this possibly related to the following discussion (which was >> coincidentally discussed today as well on tomcat user list) ? >> >> http://tomcat.10.n6.nabble.com/jdbc-pool-Transaction-left-open-by-the-connection-validation-mechanism-td4991758.html
Re: JDBC connection pool memory leak
Hi Romain, I have a tiny tarball with sources and build.xml available here: http://dev.cuspycode.se/public/poolbugtest.tar.gz Look in README.txt for further instructions. I made the example as small as I could, it's very tiny, but there are a few steps to go through since a database needs to be created etc. I stumbled upon another thing while isolating this: it turns out that having a ValidationQuery is important. I use the query SELECT * FROM MYTABLE. When I remove this, the memory leak goes away. I also tested two more databases, Postgresql and Microsoft Azure SQL. Like Derby before, neither of them showed any increase in memory. So something strange is happening when the Mysql driver and the Tomcat-JDBC pool are interacting via JPA. -- Bjorn Danielsson Cuspy Code AB Romain Manni-Bucau wrote: > ok so can you share a sample reproducing the issue please? > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2013/1/4 Bjorn Danielsson : >> Romain Manni-Bucau wrote: >>> >>> just to be sure to understand: >>> >>> in a plain tomcat does StatementFinalizer replace stmt.close() to make >>> the leak going away? >> >> Yes. >> >> -- >> Bjorn Danielsson >> Cuspy Code AB
Re: JDBC connection pool memory leak
Romain Manni-Bucau wrote: > > just to be sure to understand: > > in a plain tomcat does StatementFinalizer replace stmt.close() to make > the leak going away? Yes. -- Bjorn Danielsson Cuspy Code AB
Re: JDBC connection pool memory leak
I just reproduced the memory leak in a plain Tomcat 7.0.34,
using only JDBC and a Mysql datasource:
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("java:/comp/env/jdbc/test");
Connection conn = ds.getConnection();
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM MYTABLE");
ResultSet rs = stmt.executeQuery();
conn.close();
I put the above code in a JSP file, then after each request I
did "jmap -histo:live 4711 | grep com.mysql.jdbc.JDBC4".
The numbers increment steadily.
Adding stmt.close() before conn.close() makes the leak go away.
Using jdbcInterceptors="StatementFinalizer" in the pool helps.
This seems to be the documented way to deal with this. However
when I tried "StatementFinalizer" in TomEE it had no effect.
The attribute was recognized, because if I misspelled the value
I got an error message in TomEE's catalina.out.
With Tomcat and commons-dbcp (the default) it was impossible
to reproduce the memory leak even when I neglected to close
the Connection proxy.
I can provide an isolated TomEE example that reproduces the
problem, but I need to disentangle it from my main project
code first.
--
Bjorn Danielsson
Cuspy Code AB
Romain Manni-Bucau wrote:
> Hi,
>
> did you try to reproduce it with tomcat-jdbc (in a simple test without
> tomee or any other framework)?
>
> i wonder if it is linked to tomee or tomcat-jdbc directly (or mysql
> since derby seems fine)
>
> any more info or even a test reproducing the issue (in a reasonnable
> time) would be great.
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/1/3 Howard W. Smith, Jr. :
>> Very interesting info here, thanks for sharing.
>>
>> I have been using TomEE since 1.5.1-SNAPSHOT and now 1.5.2-SNAPSHOT. Also,
>> I'm using Apache Derby 10.9.1.0 and Eclipse 2.3.2, and JDBC configured in
>> tomee.xml.
>>
>> Can you share your JDBC config from your tomee.xml and/or context.xml?
>>
>> Apache Derby is working fine for me, but I think I'm experiencing memory
>> leaks that are possibly caused by Google Calendar API's use of
>> threadlocal/etc... No need to discuss that here in this thread.
>>
>>
>> On Thu, Jan 3, 2013 at 1:54 PM, Bjorn Danielsson <
>> bjorn-apa...@lists.cuspycode.com> wrote:
>>
>>> It doesn't matter if I use Eclipselink instead of OpenJPA.
>>>
>>> But the memory leak goes away if I change the database from Mysql
>>> to embedded Derby, so I assume there is some quirkiness in the
>>> Mysql driver that is involved.
>>>
JDBC connection pool memory leak
Hi people,
I get memory leaks from the built-in TomEE JDBC connection pool,
using the default container-managed persistence and transactions.
I have some code in a Singleton EJB that does, essentially, this:
@PersistenceUnit(unitName = "MyApp")
EntityManagerFactory emf;
@Schedule(second="*/10", minute="*", hour="*")
public void tickTock() {
EntityManager em = emf.createEntityManager();
em.find(MyTrivialEntity.class, 1);
}
Every time tickTock() is invoked, jmap -histo:live reports objects
being added permanently to the heap:
num #instances #bytes class name
--
[...]
270: 6 1584 com.mysql.jdbc.JDBC4PreparedStatement
322: 6 1056 com.mysql.jdbc.JDBC4ResultSet
These #instances and #bytes values increase at a steady pace,
and if I leave it running long enough this causes OutOfMemory.
The number of connections doesn't grow: both mysqladmin and jmap
consistently report 3 simultaneous connections all the time.
It doesn't matter if I use Eclipselink instead of OpenJPA.
But the memory leak goes away if I change the database from Mysql
to embedded Derby, so I assume there is some quirkiness in the
Mysql driver that is involved.
The memory leak also goes away if I revert to using commons-dbcp
for the pool.
MaxAge is a workaround, but how do I choose for any
specific load? This is not an attractive solution.
I searched a lot before I posted this, and I found recommendations
that you should always close SQL Statements and ResultSets before
returning connections to the pool. But I have to trust the container
to do this when I am using JPA, right? Or am I missing something?
Version info:
apache-tomee-1.5.1-plus (I also tried today's 1.5.2 snapshot)
mysql-connector-java-5.1.22
jdk-7u9
--
Bjorn Danielsson
Cuspy Code AB
Re: Very poor performance when writing into db
In a minimalistic test, I got ~20 records per second with Eclipselink on TomEE with MySQL database on 7200-rpm RAID-1, and ~140 records/s on an SSD. The filesystem was ext4 with the default options data=ordered,barrier=1 on both occasions, and a KVM virtualization layer at the bottom. Does your app have a lot of concurrency in the JPA transactions? That's the only situation where I have seen slow performance from Eclipselink, due to lock wait timeouts in MySQL UPDATE statements. -- Bjorn Danielsson Cuspy Code AB tex wrote: > Hi, > > I've just installed Tomee 1.0 Web Profile, I've copied eclipse* jar into the > lib folder (EclipseLink JPA 2.0 persistence provider) and started the server > with 512MB of heap (on a 4GB Notebook Ubuntu workstation). > > The startup of Tomee was fine, my app was deployed but when I run my > datapump process (reading data from CSV and writing to entity beans on MySQL > db) the process is about 40x slower than Glassfish. > > Apache tomee 1.0.0 web profile: process 1 csv record every 3 seconds (0.3 > records/sec on empty db) > Glassfish 3.1.2.2: process 12 csv records every 1 second (12 records/sec on > empty db) > > To test the speed I've put System.out.println messages, maybe Glassfish has > some optimizations for these kind of messages ? > > The only strange thing I've noticed is that I've some warnings at tomee > startup: > > Can't load log handler "1catalina.org.apache.juli.FileHandler" > java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler > Can't load log handler "1catalina.org.apache.juli.FileHandler" > java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler > Can't load log handler "2localhost.org.apache.juli.FileHandler" > java.lang.ClassNotFoundException: 2localhost.org.apache.juli.FileHandler > Can't load log handler "3manager.org.apache.juli.FileHandler" > java.lang.ClassNotFoundException: 3manager.org.apache.juli.FileHandler > Can't load log handler "4host-manager.org.apache.juli.FileHandler" > java.lang.ClassNotFoundException: 4host-manager.org.apache.juli.FileHandler > > I cannot understand, must I configure something into Tomee to speed up my > session/entity beans ? > > Many thanks in advance... > > > > -- > View this message in context: > http://openejb.979440.n4.nabble.com/Very-poor-performance-when-writing-into-db-tp4657289.html > Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: READ_COMMITTED configuration exception
Doesn't work, properties comments must be at the beginning of the line. I use in tomee.xml, it's stripped by the XML parser so it works for the properties sections too. -- Bjorn Danielsson Cuspy Code AB Romain Manni-Bucau wrote: > guess you need the properties format no? > > DefaultTransactionIsolation = 2 # READ_COMMITTED > > *Romain Manni-Bucau* > *Twitter: @rmannibucau* > *Blog: http://rmannibucau.wordpress.com* > > > > > 2012/8/24 Bjorn Danielsson > >> Since the properties are embedded in XML, you can put in a >> comment after the integer constant: >> >> DefaultTransactionIsolation 2 >> >> -- >> Bjorn Danielsson >> Cuspy Code AB >> >> >> Diego Cattelan wrote: >> > on apache-tomee-1.1.0-20120824.041036-118-webprofile >> > >> > when using READ_COMMITTED on Resource.xml >> > >> > >> > ... >> > defaultTransactionIsolation READ_COMMITTED >> > ... >> > >> > >> > i'm getting an exception >> > >> > SEVERE: Unable to deploy collapsed ear in war >> > >> StandardEngine[Catalina].StandardHost[localhost].StandardContext[/ninphea_1] >> > org.apache.xbean.recipe.ConstructionException: Error invoking factory >> > method: public static javax.sql.DataSource >> > >> org.apache.openejb.resource.jdbc.DataSourceFactory.create(java.lang.String,boolean,java.lang.Class,java.lang.String) >> > throws >> > >> java.lang.IllegalAccessException,java.lang.InstantiationException,java.io.IOException >> > at >> > >> org.apache.xbean.recipe.ReflectionUtil$StaticFactory.create(ReflectionUtil.java:1006) >> > at >> > >> org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276) >> > at >> > org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) >> > at >> > org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) >> > at >> > org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:49) >> > at >> > >> org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:1642) >> > at >> > >> org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:387) >> > at >> > >> org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:1843) >> > at >> > >> org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:921) >> > at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:168) >> > at >> > >> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:352) >> > at >> > >> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:839) >> > at >> > >> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:781) >> > at >> > >> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:736) >> > at >> > >> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:118) >> > at >> > >> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) >> > at >> > >> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) >> > at >> > >> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5173) >> > at >> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) >> > at >> > >> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) >> > at >> > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) >> > at >> > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:618) >> > at >> > >> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:650) >> > at >> > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:531) >> > at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1468) >> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> > at >> > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> > at >> > >> s
Re: READ_COMMITTED configuration exception
Since the properties are embedded in XML, you can put in a comment after the integer constant: DefaultTransactionIsolation 2 -- Bjorn Danielsson Cuspy Code AB Diego Cattelan wrote: > on apache-tomee-1.1.0-20120824.041036-118-webprofile > > when using READ_COMMITTED on Resource.xml > > > ... > defaultTransactionIsolation READ_COMMITTED > ... > > > i'm getting an exception > > SEVERE: Unable to deploy collapsed ear in war > StandardEngine[Catalina].StandardHost[localhost].StandardContext[/ninphea_1] > org.apache.xbean.recipe.ConstructionException: Error invoking factory > method: public static javax.sql.DataSource > org.apache.openejb.resource.jdbc.DataSourceFactory.create(java.lang.String,boolean,java.lang.Class,java.lang.String) > throws > java.lang.IllegalAccessException,java.lang.InstantiationException,java.io.IOException > at > org.apache.xbean.recipe.ReflectionUtil$StaticFactory.create(ReflectionUtil.java:1006) > at > org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276) > at > org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) > at > org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) > at > org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:49) > at > org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:1642) > at > org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:387) > at > org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:1843) > at > org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:921) > at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:168) > at > org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:352) > at > org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:839) > at > org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:781) > at > org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:736) > at > org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:118) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5173) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:618) > at > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:650) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:531) > at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1468) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) > at > org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1436) > at > org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:856) > at > org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:353) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.S
Re: Number of simultaneous @Asynchronous threads
Great! I'll give it a try when you update. I use @Timeout also,
but I haven't been stress-testing that stuff as much yet.
According to the docs, PriorityBlockingQueue is always unbounded,
so at least one other queue type would be needed if bounded queues
are to be an option (making MaximumPoolSize meaningful).
--
Björn Danielsson
Cuspy Code AB
David Blevins wrote:
> On Aug 21, 2012, at 2:18 AM, Bjorn Danielsson wrote:
>
>> In my opinion this is a bit overkill, at least the options for
>> using DelayQueue and PriorityBlockingQueue. They require the
>> Runnable queue elements to implement the Delayed and Comparable
>> interfaces, respectively. I don't see how to make use of that in
>> an EJB method call.
>
> Agreed. Though now my mind is wondering if we should tag the runnables with
> the number of retries and have them support higher priority retry. That's
> not applicable to the @Asynchronous support, but is a feature of the
> @Timeout/EJB Timer stuff which uses an identical executor. (i'm reworking
> that code too to get everything as consistent as possible)
>
> We might even be able to support a @Priority(0.5) annotation or something for
> @Asynchronous methods. Could be interesting.
>
>> I looked at the Sun ThreadPoolExecutor docs and have now played
>> a little with it in a standalone program. I honestly think the
>> design is a bit bizarre. I would expect the thread pool to expand
>> to max capacity before tasks are put in the wait queue. For the
>> purpose of optimizing CPU core utilization, the number of threads
>> in the operating system run-queue is the only important number,
>> not the number of provisioned threads in a JVM thread pool.
>> But this is slightly off-topic here.
>>
>> I believe it's enough to have just one more configuration
>> property for TomEE: AsynchronousPool.QueueSize. If this is 0,
>> let the container use a SynchronousQueue. Otherwise use a
>> LinkedBlockingQueue with the specified capacity. That way it's
>> possible to have any of the three queueing strategies mentioned
>> in the ThreadPoolExecutor javadocs. I can't imagine a situation
>> where using an ArrayBlockingQueue instead of a bounded
>> LinkedBlockingQueue in TomEE really makes a big difference,
>> but I could be wrong about that.
>
> Hacking again, will repost and see what you think. As mentioned above, also
> cleaning up the EJB Timer @Timeout execution queue and any others I can find.
>
>
> -David
>
>>
>> David Blevins wrote:
>>> On Aug 20, 2012, at 10:55 AM, Romain Manni-Bucau wrote:
>>>
>>>> that's because we use a linked blocking queue
>>>>
>>>> maybe we should make it configurable, not sure...
>>>
>>>
>>> Made it configurable. Code is basically:
>>>
>>>public static AsynchronousPool create(AppContext appContext) {
>>>final Options options = appContext.getOptions();
>>>
>>>final String id = appContext.getId();
>>>final int corePoolSize =
>>> options.get("AsynchronousPool.CorePoolSize", 10);
>>>final int maximumPoolSize =
>>> Math.max(options.get("AsynchronousPool.MaximumPoolSize", 20), corePoolSize);
>>>final Duration keepAliveTime =
>>> options.get("AsynchronousPool.KeepAliveTime", new Duration(60,
>>> TimeUnit.SECONDS));
>>>final BlockingQueue queue =
>>> options.get("AsynchronousPool.QueueType", QueueType.LINKED).create(options);
>>>
>>>return new AsynchronousPool(id, corePoolSize, maximumPoolSize,
>>> keepAliveTime, queue);
>>>}
>>>
>>>private static enum QueueType {
>>>ARRAY,
>>>DELAY,
>>>LINKED,
>>>PRIORITY,
>>>SYNCHRONOUS;
>>>
>>>public BlockingQueue create(Options options) {
>>>switch (this) {
>>>case ARRAY: {
>>>return new
>>> ArrayBlockingQueue(options.get("AsynchronousPool.QueueSize", 100));
>>>}
>>>case DELAY: {
>>>return new DelayQueue();
>>>}
>>>case LINKED: {
>>>return new
>>> LinkedBlockingQueue(options.get("AsynchronousPool.QueueSize",
>>> Integer.MAX_VALUE));
>>>}
>>>case PRIORITY: {
>>>return new PriorityBlockingQueue();
>>>}
>>>case SYNCHRONOUS: {
>>>return new
>>> SynchronousQueue(options.get("AsynchronousPool.QueueFair", false));
>>>}
>>>default: {
>>>// The Options class will throw an error if the user
>>> supplies an unknown enum string
>>>// The only way we can reach this is if we add a new
>>> QueueType element and forget to
>>>// implement it in the above switch statement.
>>>throw new IllegalArgumentException("Unknown QueueType
>>> type: " + this);
>>>}
>>>}
>>>}
>>>}
Re: Number of simultaneous @Asynchronous threads
Can you give an example when a SynchronousQueue would block
too much? In my tests it works exactly like I would expect a
bounded queue with a size of zero to behave. The thread pool
reaches MaximumPoolSize and then a RejectedExecutionException
is thrown. For a LinkedBlockingQueue with size 1, exactly the
same thing happens but one submission later, since one element
was queued before the thread pool started to expand.
For the array vs bounded linked queue, I can't see how there
are any practical differences for a ThreadPoolExecutor except
for how memory is used to store the Runnable pointers in the
queue.
--
Björn Danielsson
Cuspy Code AB
Romain Manni-Bucau wrote:
> hmm,
>
> on the jvm implementation i personnaly think it is a good implementation
> but the unbounded linkedblockingqueue case is not the one for which the
> impl was designed IMO that's why it sounds strange i think.
>
> about the conf i prefer to not switch to synchrous queue too easily since
> it can blocks too much (could be a pity for sthg asynchronous ;)).
>
> finally between array or linked case the main difference will be the array
> case is less tolerant but i agree in an application well configured it
> shouldn't make any difference.
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
>
>
>
>
> 2012/8/21 Bjorn Danielsson
>
>> In my opinion this is a bit overkill, at least the options for
>> using DelayQueue and PriorityBlockingQueue. They require the
>> Runnable queue elements to implement the Delayed and Comparable
>> interfaces, respectively. I don't see how to make use of that in
>> an EJB method call.
>>
>> I looked at the Sun ThreadPoolExecutor docs and have now played
>> a little with it in a standalone program. I honestly think the
>> design is a bit bizarre. I would expect the thread pool to expand
>> to max capacity before tasks are put in the wait queue. For the
>> purpose of optimizing CPU core utilization, the number of threads
>> in the operating system run-queue is the only important number,
>> not the number of provisioned threads in a JVM thread pool.
>> But this is slightly off-topic here.
>>
>> I believe it's enough to have just one more configuration
>> property for TomEE: AsynchronousPool.QueueSize. If this is 0,
>> let the container use a SynchronousQueue. Otherwise use a
>> LinkedBlockingQueue with the specified capacity. That way it's
>> possible to have any of the three queueing strategies mentioned
>> in the ThreadPoolExecutor javadocs. I can't imagine a situation
>> where using an ArrayBlockingQueue instead of a bounded
>> LinkedBlockingQueue in TomEE really makes a big difference,
>> but I could be wrong about that.
>>
>> --
>> Björn Danielsson
>> Cuspy Code AB
>>
>>
>> David Blevins wrote:
>> > On Aug 20, 2012, at 10:55 AM, Romain Manni-Bucau wrote:
>> >
>> >> that's because we use a linked blocking queue
>> >>
>> >> maybe we should make it configurable, not sure...
>> >
>> >
>> > Made it configurable. Code is basically:
>> >
>> > public static AsynchronousPool create(AppContext appContext) {
>> > final Options options = appContext.getOptions();
>> >
>> > final String id = appContext.getId();
>> > final int corePoolSize =
>> options.get("AsynchronousPool.CorePoolSize", 10);
>> > final int maximumPoolSize =
>> Math.max(options.get("AsynchronousPool.MaximumPoolSize", 20), corePoolSize);
>> > final Duration keepAliveTime =
>> options.get("AsynchronousPool.KeepAliveTime", new Duration(60,
>> TimeUnit.SECONDS));
>> > final BlockingQueue queue =
>> options.get("AsynchronousPool.QueueType", QueueType.LINKED).create(options);
>> >
>> > return new AsynchronousPool(id, corePoolSize, maximumPoolSize,
>> keepAliveTime, queue);
>> > }
>> >
>> > private static enum QueueType {
>> > ARRAY,
>> > DELAY,
>> > LINKED,
>> > PRIORITY,
>> > SYNCHRONOUS;
>> >
>> > public BlockingQueue create(Options options) {
>> > switch (this) {
>> > case ARRAY: {
>> > return new
>> ArrayBlockingQueue(options.get("AsynchronousPool.QueueSize", 100));
>> > }
>> > case DELAY: {
>> > retur
Re: Number of simultaneous @Asynchronous threads
In my opinion this is a bit overkill, at least the options for
using DelayQueue and PriorityBlockingQueue. They require the
Runnable queue elements to implement the Delayed and Comparable
interfaces, respectively. I don't see how to make use of that in
an EJB method call.
I looked at the Sun ThreadPoolExecutor docs and have now played
a little with it in a standalone program. I honestly think the
design is a bit bizarre. I would expect the thread pool to expand
to max capacity before tasks are put in the wait queue. For the
purpose of optimizing CPU core utilization, the number of threads
in the operating system run-queue is the only important number,
not the number of provisioned threads in a JVM thread pool.
But this is slightly off-topic here.
I believe it's enough to have just one more configuration
property for TomEE: AsynchronousPool.QueueSize. If this is 0,
let the container use a SynchronousQueue. Otherwise use a
LinkedBlockingQueue with the specified capacity. That way it's
possible to have any of the three queueing strategies mentioned
in the ThreadPoolExecutor javadocs. I can't imagine a situation
where using an ArrayBlockingQueue instead of a bounded
LinkedBlockingQueue in TomEE really makes a big difference,
but I could be wrong about that.
--
Björn Danielsson
Cuspy Code AB
David Blevins wrote:
> On Aug 20, 2012, at 10:55 AM, Romain Manni-Bucau wrote:
>
>> that's because we use a linked blocking queue
>>
>> maybe we should make it configurable, not sure...
>
>
> Made it configurable. Code is basically:
>
> public static AsynchronousPool create(AppContext appContext) {
> final Options options = appContext.getOptions();
>
> final String id = appContext.getId();
> final int corePoolSize = options.get("AsynchronousPool.CorePoolSize",
> 10);
> final int maximumPoolSize =
> Math.max(options.get("AsynchronousPool.MaximumPoolSize", 20), corePoolSize);
> final Duration keepAliveTime =
> options.get("AsynchronousPool.KeepAliveTime", new Duration(60,
> TimeUnit.SECONDS));
> final BlockingQueue queue = options.get("AsynchronousPool.QueueType",
> QueueType.LINKED).create(options);
>
> return new AsynchronousPool(id, corePoolSize, maximumPoolSize,
> keepAliveTime, queue);
> }
>
> private static enum QueueType {
> ARRAY,
> DELAY,
> LINKED,
> PRIORITY,
> SYNCHRONOUS;
>
> public BlockingQueue create(Options options) {
> switch (this) {
> case ARRAY: {
> return new
> ArrayBlockingQueue(options.get("AsynchronousPool.QueueSize", 100));
> }
> case DELAY: {
> return new DelayQueue();
> }
> case LINKED: {
> return new
> LinkedBlockingQueue(options.get("AsynchronousPool.QueueSize",
> Integer.MAX_VALUE));
> }
> case PRIORITY: {
> return new PriorityBlockingQueue();
> }
> case SYNCHRONOUS: {
> return new
> SynchronousQueue(options.get("AsynchronousPool.QueueFair", false));
> }
> default: {
> // The Options class will throw an error if the user
> supplies an unknown enum string
> // The only way we can reach this is if we add a new
> QueueType element and forget to
> // implement it in the above switch statement.
> throw new IllegalArgumentException("Unknown QueueType
> type: " + this);
> }
> }
> }
> }
Re: Number of simultaneous @Asynchronous threads
I found out that this setting is what causes the exception: AsynchronousPool.KeepAliveTime = 60 Without it, everything is fine! I simply added all three properties for testing, though I really have no need to tweak KeepAliveTime. But just for the sake of completeness: what's the intended format for that property? Another strange thing that you mentioned earlier Romain, is that in my tests the pool size never grows to MaximumPoolSize. It always stays at CorePoolSize. I use test methods that sleep for 10 seconds and log the timestamps and the Thread names, and the results are consistent. I even tried spinning instead of sleeping, but it made no difference. -- Björn Danielsson Cuspy Code AB Romain Manni-Bucau wrote: > i don't manage to reproduce it, > > i simply put in conf/system.properties: > > AsynchronousPool.CorePoolSize = 50 > AsynchronousPool.MaximumPoolSize = 100 > > > and in the log i get: > > INFO: Using 'AsynchronousPool.CorePoolSize=50' > 20 août 2012 16:21:40 org.apache.openejb.util.OptionsLog info > INFO: Using 'AsynchronousPool.MaximumPoolSize=100' > > and no exception, > > maybe you are not completely up to date? > > *Romain Manni-Bucau* > *Twitter: @rmannibucau* > *Blog: http://rmannibucau.wordpress.com* > > > > > 2012/8/20 Bjorn Danielsson > >> I built from the latest source (r1374989) and tried the new >> configuration, but I get strange errors. Just by placing the >> default values in system.properties in a freshly unpacked >> TomEE-plus, I got this exception: >> >> INFO: Assembling app: openejb >> Aug 20, 2012 3:56:28 PM org.apache.openejb.util.OptionsLog info >> INFO: Using 'AsynchronousPool.CorePoolSize=10' >> Aug 20, 2012 3:56:28 PM org.apache.openejb.util.OptionsLog info >> INFO: Using 'AsynchronousPool.MaximumPoolSize=20' >> Aug 20, 2012 3:56:28 PM org.apache.openejb.util.OptionsLog info >> INFO: Using 'AsynchronousPool.KeepAliveTime=60' >> Aug 20, 2012 3:56:28 PM org.apache.openejb.assembler.classic.Assembler >> destroyApplication >> INFO: Undeploying app: openejb >> Aug 20, 2012 3:56:29 PM org.apache.openejb.assembler.classic.Assembler >> buildContainerSystem >> SEVERE: Application could not be deployed: openejb >> org.apache.openejb.OpenEJBException: Creating application failed: openejb: >> null >> at >> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:929) >> at >> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:521) >> at >> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:422) >> at >> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:330) >> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:144) >> at org.apache.openejb.OpenEJB.init(OpenEJB.java:290) >> at >> org.apache.tomee.catalina.TomcatLoader.initialize(TomcatLoader.java:231) >> at >> org.apache.tomee.catalina.TomcatLoader.init(TomcatLoader.java:131) >> at >> org.apache.tomee.catalina.ServerListener.lifecycleEvent(ServerListener.java:113) >> at >> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) >> at >> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) >> at >> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401) >> at >> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) >> at org.apache.catalina.startup.Catalina.load(Catalina.java:624) >> at org.apache.catalina.startup.Catalina.load(Catalina.java:649) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:601) >> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) >> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450) >> Caused by: java.lang.NullPointerException >> at >> java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1281) >> at >> java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1198) >> at >> org.apache.openejb.async.AsynchronousPool.(AsynchronousPool.java:51) >> at >> org.apache.openejb.async.AsynchronousPool.cr
Re: Number of simultaneous @Asynchronous threads
I built from the latest source (r1374989) and tried the new configuration, but I get strange errors. Just by placing the default values in system.properties in a freshly unpacked TomEE-plus, I got this exception: INFO: Assembling app: openejb Aug 20, 2012 3:56:28 PM org.apache.openejb.util.OptionsLog info INFO: Using 'AsynchronousPool.CorePoolSize=10' Aug 20, 2012 3:56:28 PM org.apache.openejb.util.OptionsLog info INFO: Using 'AsynchronousPool.MaximumPoolSize=20' Aug 20, 2012 3:56:28 PM org.apache.openejb.util.OptionsLog info INFO: Using 'AsynchronousPool.KeepAliveTime=60' Aug 20, 2012 3:56:28 PM org.apache.openejb.assembler.classic.Assembler destroyApplication INFO: Undeploying app: openejb Aug 20, 2012 3:56:29 PM org.apache.openejb.assembler.classic.Assembler buildContainerSystem SEVERE: Application could not be deployed: openejb org.apache.openejb.OpenEJBException: Creating application failed: openejb: null at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:929) at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:521) at org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:422) at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:330) at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:144) at org.apache.openejb.OpenEJB.init(OpenEJB.java:290) at org.apache.tomee.catalina.TomcatLoader.initialize(TomcatLoader.java:231) at org.apache.tomee.catalina.TomcatLoader.init(TomcatLoader.java:131) at org.apache.tomee.catalina.ServerListener.lifecycleEvent(ServerListener.java:113) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) at org.apache.catalina.startup.Catalina.load(Catalina.java:624) at org.apache.catalina.startup.Catalina.load(Catalina.java:649) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450) Caused by: java.lang.NullPointerException at java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1281) at java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1198) at org.apache.openejb.async.AsynchronousPool.(AsynchronousPool.java:51) at org.apache.openejb.async.AsynchronousPool.create(AsynchronousPool.java:66) at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:589) ... 20 more I also tried deploying my webapp and moved the properties to WEB-INF/application.properties, and that produced a similar exception with the same cause, but for my app instead of openejb and with some differences in the lifecycle call chain. -- Björn Danielsson Cuspy Code AB Romain Manni-Bucau wrote: > FYI, with last David refactoring the config is a bit different from the one > i did, just to keep a track in this thread (jira is up to date), properties > are and can be put in application.properties (META-INF or WEB-INF): > > AsynchronousPool.CorePoolSize > AsynchronousPool.MaximumPoolSize > AsynchronousPool.KeepAliveTime > > *Romain Manni-Bucau* > *Twitter: @rmannibucau* > *Blog: http://rmannibucau.wordpress.com* > > > > > 2012/8/20 zeeman > >> Great, thanks. >> >> >> >> -- >> View this message in context: >> http://openejb.979440.n4.nabble.com/Number-of-simultaneous-Asynchronous-threads-tp4656891p4656908.html >> Sent from the OpenEJB User mailing list archive at Nabble.com. >>
Number of simultaneous @Asynchronous threads
Hi guys, Is there some way to configure the size of the thread pool used for @Asynchronous execution of session bean methods? I can't get more than 10 simultaneous threads executing @Asynchronous methods, and I didn't find any obvious setting for this in tomee.xml or service-jar.xml. Version info: apache-tomee-1.1.0-20120817.135055-110-plus -- Björn Danielsson Cuspy Code AB
Re: Anyone have experience with alternative JMS providers?
Update on my attempt to integrate Apache Qpid with TomEE. I had to abandon the GenericJMSRA approach because the only Queue implementation class I found in the Qpid client (which was org.apache.qpid.client.AMQQueue) could not be constructed by the genericra ObjectBuilderFactory, because the class had protected members. But I found that there is a resource adapter for Qpid included in the source code. I haven't tried it with the bundled-in-EAR deployment method because I am more interested in seeing if this can be done in the container. So I created a service-jar.xml for this Qpid Resource Adapter, working from David's GenericJMSRA example and the Qpid source code. One patch was needed for the Qpid Resource Adapter: it has a property "TransactionManagerLocatorClass" which is used to find the container's TransactionManager. Different methods were used for different containers, and I had to add one for TomEE, which I did by cloning the one for Glassfish and changing the JNDI name for the TransactionManager. Then I got stuck. I get a JNDI NameNotFoundException from the Qpid Activation thingy complaining about my JMS destination names when my MDBs are created. Probably a Qpid bug. I don't think I'll spend any more effort on making Qpid work with TomEE. My original motivation was to try out alternatives to ActiveMQ for my project, not to make Qpid work at all costs. I might try with another JMS provider, and in that case I'll post about it here of course. -- Björn Danielsson Cuspy Code AB
Re: Anyone have experience with alternative JMS providers?
I tried editing again after posting that (I'm a stubborn guy :) and now I could edit with login... -- Björn Danielsson Romain Manni-Bucau wrote: > should be sync soon > > - Romain > > > 2012/6/27 Bjorn Danielsson > >> Aha, that worked, and the short type-name works now. Thanks! >> >> Someone should update the wiki page to say >> >>provider="org.superbiz:genericra" >> >> instead of >> >>provider="org.superbiz" >> >> I can't edit, I got a login prompt for ASF Committers when I tried. >> >> -- >> Björn Danielsson >> Cuspy Code AB >> >> >> Romain Manni-Bucau wrote: >> > as you specified type, specufy the provider: >> > >> > provider="com.example:myProvId" >> > >> > - Romain >> > >> > >> > 2012/6/27 Bjorn Danielsson >> > >> >> Yes, I did. I think loading-by-provider may be broken, because I >> >> peeked at the TomEE source and found that if the provider is null >> >> it will find by type. So I made it work by removing the provider >> >> attribute in tomee.xml, and giving the full classname as the type: >> >> >> >> > >> type="com.sun.genericra.GenericJMSRA"> >> >> >> >> >> >> And I made the corresponding name change in service-jar.xml: >> >> >> >>types="com.sun.genericra.GenericJMSRA" >> >> >> >> instead of >> >> >> >>types="GenericJMSRA" >> >> >> >> Without this it wouldn't find the class. Maybe there is some >> >> other way to make the short type-name work, but these changes >> >> were enough to get the resource created. >> >> >> >> Then I deployed my webapp and got some new errors, but I haven't >> >> really started configuring the adapter yet, so I'll get back >> >> here again when I have tried that. >> >> >> >> -- >> >> Björn Danielsson >> >> Cuspy Code AB >> >> >> >> >> >> Romain Manni-Bucau wrote: >> >> > did you put it in tomee/lib? >> >> > >> >> > - Romain >> >> > >> >> > >> >> > 2012/6/27 Bjorn Danielsson >> >> > >> >> >> Thanks! >> >> >> >> >> >> Here is my first question (and stumbling block). I tried the second >> >> >> method on the wiki page, using the Generic JMS Resource Adapter to >> >> >> integrate an Apache Qpid client. But TomEE complained that it didn't >> >> >> find the provider: >> >> >> >> >> >> Jun 27, 2012 2:05:58 PM >> org.apache.openejb.config.ConfigurationFactory >> >> >> configureService >> >> >> SEVERE: Failed Configuring Service(id=My Other JMS Resource Adapter) >> >> >> org.apache.openejb.config.NoSuchProviderException: Cannot find the >> >> >> ServiceProvider id com.example in the service-jar.xml at com.example. >> >> Check >> >> >> that your OpenEJB configuration file is point to the right >> >> ServiceProvider >> >> >> id." >> >> >>at >> >> >> >> >> >> org.apache.openejb.config.ServiceUtils.getServiceProvider(ServiceUtils.java:114) >> >> >>at >> >> >> >> >> >> org.apache.openejb.config.ConfigurationFactory.resolveServiceProvider(ConfigurationFactory.java:1025) >> >> >>at >> >> >> >> >> >> org.apache.openejb.config.ConfigurationFactory.configureService(ConfigurationFactory.java:887) >> >> >>at >> >> >> >> >> >> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:403) >> >> >> [...] >> >> >> >> >> >> This is my resource declaration in tomee.xml: >> >> >> >> >> >> > >> >> provider="com.example"> >> >> >> >> >> >> >> >> >> And this is the jar I put in $CATALINA_HOME/lib to package >> >> service-jar.xml: >> >> >> >> >> >> # jar tvf tomee-qpid.jar >> >> >> 0 Wed Jun 27 14:02:02 CEST
Re: Anyone have experience with alternative JMS providers?
Aha, that worked, and the short type-name works now. Thanks! Someone should update the wiki page to say provider="org.superbiz:genericra" instead of provider="org.superbiz" I can't edit, I got a login prompt for ASF Committers when I tried. -- Björn Danielsson Cuspy Code AB Romain Manni-Bucau wrote: > as you specified type, specufy the provider: > > provider="com.example:myProvId" > > - Romain > > > 2012/6/27 Bjorn Danielsson > >> Yes, I did. I think loading-by-provider may be broken, because I >> peeked at the TomEE source and found that if the provider is null >> it will find by type. So I made it work by removing the provider >> attribute in tomee.xml, and giving the full classname as the type: >> >> > type="com.sun.genericra.GenericJMSRA"> >> >> >> And I made the corresponding name change in service-jar.xml: >> >>types="com.sun.genericra.GenericJMSRA" >> >> instead of >> >>types="GenericJMSRA" >> >> Without this it wouldn't find the class. Maybe there is some >> other way to make the short type-name work, but these changes >> were enough to get the resource created. >> >> Then I deployed my webapp and got some new errors, but I haven't >> really started configuring the adapter yet, so I'll get back >> here again when I have tried that. >> >> -- >> Björn Danielsson >> Cuspy Code AB >> >> >> Romain Manni-Bucau wrote: >> > did you put it in tomee/lib? >> > >> > - Romain >> > >> > >> > 2012/6/27 Bjorn Danielsson >> > >> >> Thanks! >> >> >> >> Here is my first question (and stumbling block). I tried the second >> >> method on the wiki page, using the Generic JMS Resource Adapter to >> >> integrate an Apache Qpid client. But TomEE complained that it didn't >> >> find the provider: >> >> >> >> Jun 27, 2012 2:05:58 PM org.apache.openejb.config.ConfigurationFactory >> >> configureService >> >> SEVERE: Failed Configuring Service(id=My Other JMS Resource Adapter) >> >> org.apache.openejb.config.NoSuchProviderException: Cannot find the >> >> ServiceProvider id com.example in the service-jar.xml at com.example. >> Check >> >> that your OpenEJB configuration file is point to the right >> ServiceProvider >> >> id." >> >>at >> >> >> org.apache.openejb.config.ServiceUtils.getServiceProvider(ServiceUtils.java:114) >> >>at >> >> >> org.apache.openejb.config.ConfigurationFactory.resolveServiceProvider(ConfigurationFactory.java:1025) >> >>at >> >> >> org.apache.openejb.config.ConfigurationFactory.configureService(ConfigurationFactory.java:887) >> >>at >> >> >> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:403) >> >> [...] >> >> >> >> This is my resource declaration in tomee.xml: >> >> >> >> > >> provider="com.example"> >> >> >> >> >> >> And this is the jar I put in $CATALINA_HOME/lib to package >> service-jar.xml: >> >> >> >> # jar tvf tomee-qpid.jar >> >> 0 Wed Jun 27 14:02:02 CEST 2012 META-INF/ >> >>71 Wed Jun 27 14:02:02 CEST 2012 META-INF/MANIFEST.MF >> >> 0 Wed Jun 27 12:29:38 CEST 2012 META-INF/com.example/ >> >> 2395 Wed Jun 27 12:29:38 CEST 2012 META-INF/com.example/service-jar.xml >> >> >> >> Why didn't it work? >> >> >> >> Version info: >> >> >> >> apache-tomee-1.1.0-20120627.041358-42-plus >> >> genericjmsra/v2.1a >> >> >> >> No webapps deployed, just a fresh install, easy to replicate. >> >> >> >> -- >> >> Björn Danielsson >> >> Cuspy Code AB >> >> >> >> >> >> David Blevins wrote: >> >> > On Jun 26, 2012, at 12:46 AM, Bjorn Danielsson wrote: >> >> > >> >> >> Does anyone have a recipe for using Apache Qpid or JORAM >> >> >> with TomEE-plus (i.e. replacing the bundled ActiveMQ)? >> >> >> The configuration I have in mind is a container-managed >> >> >> MDB that receives messages from an external broker. >> >> > >> >> > Created this doc for you: >> >> > >> >> > http://openejb.apache.org/changing-jms-implementations.html >> >> > >> >> > It's just an hour old, so may not fully answer the question. :) >> >> > >> >> > Between the two of us I'm sure we can perfect it. You can use the >> >> little blue pencil icon in the upper right to edit. Feel free to tweak >> it >> >> as much as you like and feel free to keep asking questions. >> >> > >> >> > One of the areas we really need to document better. The last time >> this >> >> came up it didn't go beyond the mailing list, so hopefully this time we >> can >> >> capture the steps more permanently :) >> >> > >> >> > Thanks for the question! >> >> > >> >> > >> >> > -David >> >> >>
Re: Anyone have experience with alternative JMS providers?
Yes, I did. I think loading-by-provider may be broken, because I peeked at the TomEE source and found that if the provider is null it will find by type. So I made it work by removing the provider attribute in tomee.xml, and giving the full classname as the type: And I made the corresponding name change in service-jar.xml: types="com.sun.genericra.GenericJMSRA" instead of types="GenericJMSRA" Without this it wouldn't find the class. Maybe there is some other way to make the short type-name work, but these changes were enough to get the resource created. Then I deployed my webapp and got some new errors, but I haven't really started configuring the adapter yet, so I'll get back here again when I have tried that. -- Björn Danielsson Cuspy Code AB Romain Manni-Bucau wrote: > did you put it in tomee/lib? > > - Romain > > > 2012/6/27 Bjorn Danielsson > >> Thanks! >> >> Here is my first question (and stumbling block). I tried the second >> method on the wiki page, using the Generic JMS Resource Adapter to >> integrate an Apache Qpid client. But TomEE complained that it didn't >> find the provider: >> >> Jun 27, 2012 2:05:58 PM org.apache.openejb.config.ConfigurationFactory >> configureService >> SEVERE: Failed Configuring Service(id=My Other JMS Resource Adapter) >> org.apache.openejb.config.NoSuchProviderException: Cannot find the >> ServiceProvider id com.example in the service-jar.xml at com.example. Check >> that your OpenEJB configuration file is point to the right ServiceProvider >> id." >>at >> org.apache.openejb.config.ServiceUtils.getServiceProvider(ServiceUtils.java:114) >>at >> org.apache.openejb.config.ConfigurationFactory.resolveServiceProvider(ConfigurationFactory.java:1025) >>at >> org.apache.openejb.config.ConfigurationFactory.configureService(ConfigurationFactory.java:887) >>at >> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:403) >> [...] >> >> This is my resource declaration in tomee.xml: >> >> > provider="com.example"> >> >> >> And this is the jar I put in $CATALINA_HOME/lib to package service-jar.xml: >> >> # jar tvf tomee-qpid.jar >> 0 Wed Jun 27 14:02:02 CEST 2012 META-INF/ >>71 Wed Jun 27 14:02:02 CEST 2012 META-INF/MANIFEST.MF >> 0 Wed Jun 27 12:29:38 CEST 2012 META-INF/com.example/ >> 2395 Wed Jun 27 12:29:38 CEST 2012 META-INF/com.example/service-jar.xml >> >> Why didn't it work? >> >> Version info: >> >> apache-tomee-1.1.0-20120627.041358-42-plus >> genericjmsra/v2.1a >> >> No webapps deployed, just a fresh install, easy to replicate. >> >> -- >> Björn Danielsson >> Cuspy Code AB >> >> >> David Blevins wrote: >> > On Jun 26, 2012, at 12:46 AM, Bjorn Danielsson wrote: >> > >> >> Does anyone have a recipe for using Apache Qpid or JORAM >> >> with TomEE-plus (i.e. replacing the bundled ActiveMQ)? >> >> The configuration I have in mind is a container-managed >> >> MDB that receives messages from an external broker. >> > >> > Created this doc for you: >> > >> > http://openejb.apache.org/changing-jms-implementations.html >> > >> > It's just an hour old, so may not fully answer the question. :) >> > >> > Between the two of us I'm sure we can perfect it. You can use the >> little blue pencil icon in the upper right to edit. Feel free to tweak it >> as much as you like and feel free to keep asking questions. >> > >> > One of the areas we really need to document better. The last time this >> came up it didn't go beyond the mailing list, so hopefully this time we can >> capture the steps more permanently :) >> > >> > Thanks for the question! >> > >> > >> > -David >>
Re: Anyone have experience with alternative JMS providers?
Thanks! Here is my first question (and stumbling block). I tried the second method on the wiki page, using the Generic JMS Resource Adapter to integrate an Apache Qpid client. But TomEE complained that it didn't find the provider: Jun 27, 2012 2:05:58 PM org.apache.openejb.config.ConfigurationFactory configureService SEVERE: Failed Configuring Service(id=My Other JMS Resource Adapter) org.apache.openejb.config.NoSuchProviderException: Cannot find the ServiceProvider id com.example in the service-jar.xml at com.example. Check that your OpenEJB configuration file is point to the right ServiceProvider id." at org.apache.openejb.config.ServiceUtils.getServiceProvider(ServiceUtils.java:114) at org.apache.openejb.config.ConfigurationFactory.resolveServiceProvider(ConfigurationFactory.java:1025) at org.apache.openejb.config.ConfigurationFactory.configureService(ConfigurationFactory.java:887) at org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:403) [...] This is my resource declaration in tomee.xml: And this is the jar I put in $CATALINA_HOME/lib to package service-jar.xml: # jar tvf tomee-qpid.jar 0 Wed Jun 27 14:02:02 CEST 2012 META-INF/ 71 Wed Jun 27 14:02:02 CEST 2012 META-INF/MANIFEST.MF 0 Wed Jun 27 12:29:38 CEST 2012 META-INF/com.example/ 2395 Wed Jun 27 12:29:38 CEST 2012 META-INF/com.example/service-jar.xml Why didn't it work? Version info: apache-tomee-1.1.0-20120627.041358-42-plus genericjmsra/v2.1a No webapps deployed, just a fresh install, easy to replicate. -- Björn Danielsson Cuspy Code AB David Blevins wrote: > On Jun 26, 2012, at 12:46 AM, Bjorn Danielsson wrote: > >> Does anyone have a recipe for using Apache Qpid or JORAM >> with TomEE-plus (i.e. replacing the bundled ActiveMQ)? >> The configuration I have in mind is a container-managed >> MDB that receives messages from an external broker. > > Created this doc for you: > > http://openejb.apache.org/changing-jms-implementations.html > > It's just an hour old, so may not fully answer the question. :) > > Between the two of us I'm sure we can perfect it. You can use the little > blue pencil icon in the upper right to edit. Feel free to tweak it as much > as you like and feel free to keep asking questions. > > One of the areas we really need to document better. The last time this came > up it didn't go beyond the mailing list, so hopefully this time we can > capture the steps more permanently :) > > Thanks for the question! > > > -David
Anyone have experience with alternative JMS providers?
Does anyone have a recipe for using Apache Qpid or JORAM with TomEE-plus (i.e. replacing the bundled ActiveMQ)? The configuration I have in mind is a container-managed MDB that receives messages from an external broker. -- Björn Danielsson Cuspy Code AB
Re: Tomee Plus instead of Glassfish
I distinctly remember having seen the combo @Local @Stateless
in a Glassfish tutorial a few years ago, because I copied from
that tutorial and used the code for a while (in Glassfish 2.1)
until I ran into some unrelated problem that made me rewrite
all my annotations.
--
Björn Danielsson
Cuspy Code AB
Jean-Louis MONTEIRO wrote:
> David,
>
> Not sure how to understand that post content.
> IMO, a @Local annotation (without any interface specified) on the bean
> class is not allowed by the spec.
>
> JLouis
>
> 2012/6/4 David Blevins
>
>>
>> On Jun 3, 2012, at 9:18 AM, Marco de Booij wrote:
>> > @Local
>> > @Stateless(name="I18nCodeManager")
>> > public class I18nCodeManager {
>> > @EJB
>> > private I18nCodeDao i18nCodeDao;
>> >
>>
>> Strangely enough we're seeing a lot of portability issues on GlassFish's
>> handling of @Local.
>>
>> Some JBoss friends just pinged me the other day with this:
>>
>> https://issues.jboss.org/browse/WELD-1133
>>
>> As well another user recently reported this:
>>
>> https://issues.apache.org/jira/browse/OPENEJB-1818
>>
>> Three GlassFish @Local issues reported in less than a month.
>>
>>
>> -David
>>
>>
Re: How do you shut down ActiveMQ transport?
I use an empty BrokerXmlConfig in TomEE+ (which is only a JMS client with a couple of MDBs in this scenario) and then this url: ServerUrl tcp://remote.host.name:61616 The remote host uses a standalone ActiveMQ default configuration, fresh out of the box. I think useShutdownHook only applies on the server end. After some more suspicions and testing I found that using NIO on the client works better: ServerUrl nio://remote.host.name:61616 This allows the transport thread to shut down immediately. -- Björn Danielsson Cuspy Code AB AndyG wrote: > Can you provide your broker configuration/url. > > You probably just need to add 'useShutdownHook=true'. > > Andy. > > -- > View this message in context: > http://openejb.979440.n4.nabble.com/How-do-you-shut-down-ActiveMQ-transport-tp4655255p4655295.html > Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: How do you shut down ActiveMQ transport?
Thanks for the info on -force, that is certainly useful in many situations. I wish I had known that years ago! -- Björn Danielsson Cuspy Code AB "Filip Hanik (mailing lists)" wrote: > Tomcat has a force shutdown option. Make sure you set CATALINA_PID variable > to point to a file name, for example in > > setenv.sh put > > CATALINA_PID=$CATALINA_BASE/logs/tomcat.pid > > Then, call './shutdown.sh -force' > > This will use unix kill and kill -9 as opposed to trying to connect into the > JVM. > Tomcat first issues a regular 'kill' and then gives the JVM some time to > exit, if the jvm doesn't exit, it terminates the process. > This is the preferred way to shutdown, since a OutofMemoryError in your > application may leave the JVM hanging. > > > > Filip > >> -Original Message- >> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] >> Sent: Thursday, May 31, 2012 11:31 AM >> To: users@openejb.apache.org >> Subject: Re: How do you shut down ActiveMQ transport? >> >> Hi, >> >> Dont have it in head but i think AMQ has some url options to shutdown >> quickly >> >> Maybe try to add daemon option to true >> >> - Romain >> Le 31 mai 2012 18:55, "Bjorn Danielsson" > apa...@lists.cuspycode.com> >> a écrit : >> >> > Hi guys, >> > >> > I just noticed that TomEE-plus takes a very long time >> > to shutdown if a remote ActiveMQ broker is being used. >> > Has anyone else seen this behaviour? Or could I be doing >> > something strange that causes this? >> > >> > When running "shutdown.sh" Tomcat stops all webapps as >> > usual, but it takes somewhere between 10-30 minutes before >> > the JVM terminates. During that time two TCP connections >> > to the remote broker are kept open. >> > >> > The same application using a "tcp://localhost:61616" broker >> > hosted within TomEE shuts down immediately as expected. >> > >> > Version info: >> > >> > apache-tomee-1.1.0-20120531.144231-5-plus >> > apache-activemq-5.6.0 (on the remote host, using default conf) >> > >> > -- >> > Björn Danielsson >> > Cuspy Code AB >> >
How do you shut down ActiveMQ transport?
Hi guys, I just noticed that TomEE-plus takes a very long time to shutdown if a remote ActiveMQ broker is being used. Has anyone else seen this behaviour? Or could I be doing something strange that causes this? When running "shutdown.sh" Tomcat stops all webapps as usual, but it takes somewhere between 10-30 minutes before the JVM terminates. During that time two TCP connections to the remote broker are kept open. The same application using a "tcp://localhost:61616" broker hosted within TomEE shuts down immediately as expected. Version info: apache-tomee-1.1.0-20120531.144231-5-plus apache-activemq-5.6.0 (on the remote host, using default conf) -- Björn Danielsson Cuspy Code AB
Re: Bug: endorsed JAXB is broken
Thanks Romain!
I can confirm that my webapp now works with this night's snapshot.
--
Björn Danielsson
Cuspy Code AB
Romain Manni-Bucau wrote:
> should be fine on trunk now
>
> - Romain
>
>
> 2012/5/3 Bjorn Danielsson
>
>> Aha, so the class signature works. I use the String signature:
>>
>> JAXBContext ctx = JAXBContext.newInstance("com.example.jaxb.mypkg");
>>
>> Actually I just noticed that you don't need any data classes to
>> demonstrate the problem. Just call JAXBContext.newInstance("foo").
>> A working JAXB should give this error:
>>
>> JAXBException: "foo" doesnt contain ObjectFactory.class or jaxb.index
>>
>> instead of NoSuchMethodError.
>>
>> --
>> Björn Danielsson
>> Cuspy Code AB
>>
>>
>> Romain Manni-Bucau wrote:
>> > just tried a just build trunk and this code works:
>> >
>> > final JAXBContext ctx = JAXBContext.newInstance(XmlThing.class);
>> > final StringWriter writer = new StringWriter();
>> > ctx.createMarshaller().marshal(new XmlThing("foo"), writer);
>> >
>> > anything to reproduce your issue?
>> >
>> > - Romain
>> >
>> >
>> > 2012/5/3 Bjorn Danielsson
>> >
>> >> Hi,
>> >>
>> >> I get the following error when I try to use JAXB in my webapp:
>> >>
>> >> java.lang.NoSuchMethodError:
>> >>
>> javax.xml.bind.ContextFinder.find(Ljava/lang/String;Ljava/lang/ClassLoader;Ljava/util/Map;)Ljavax/xml/bind/JAXBContext;
>> >>
>> >> I noticed that TomEE uses an endorsed version 2.2 of JAXB,
>> >> with the ContextFinder class excluded, as mentioned here:
>> >>
>> >> https://issues.apache.org/jira/browse/TOMEE-145
>> >>
>> >> But the JVM version of JAXB does not have any ContextFinder.find()
>> >> method with the signature in my error message, so something is
>> >> obviously broken. I also checked the latest release (2.2.5) of
>> >> JAXB-RI, and there is no such signature there either.
>> >>
>> >> When I replaced the endorsed jaxb-api.jar and jaxb-impl.jar with
>> >> the corresponding jars from JAXB-RI 2.2.5 the error went away,
>> >> and as far as I can see that did not break anything else.
>> >>
>> >> Version info:
>> >>
>> >> apache-tomee-plus-1.0.0-beta-3-SNAPSHOT (from May 3)
>> >> jdk1.6.0_27 (which I think contains JAXB-RI version 2.1.10)
>> >>
>> >> --
>> >> Björn Danielsson
>> >> Cuspy Code AB
>> >>
>>
Re: Bug: endorsed JAXB is broken
Aha, so the class signature works. I use the String signature:
JAXBContext ctx = JAXBContext.newInstance("com.example.jaxb.mypkg");
Actually I just noticed that you don't need any data classes to
demonstrate the problem. Just call JAXBContext.newInstance("foo").
A working JAXB should give this error:
JAXBException: "foo" doesnt contain ObjectFactory.class or jaxb.index
instead of NoSuchMethodError.
--
Björn Danielsson
Cuspy Code AB
Romain Manni-Bucau wrote:
> just tried a just build trunk and this code works:
>
> final JAXBContext ctx = JAXBContext.newInstance(XmlThing.class);
> final StringWriter writer = new StringWriter();
> ctx.createMarshaller().marshal(new XmlThing("foo"), writer);
>
> anything to reproduce your issue?
>
> - Romain
>
>
> 2012/5/3 Bjorn Danielsson
>
>> Hi,
>>
>> I get the following error when I try to use JAXB in my webapp:
>>
>> java.lang.NoSuchMethodError:
>> javax.xml.bind.ContextFinder.find(Ljava/lang/String;Ljava/lang/ClassLoader;Ljava/util/Map;)Ljavax/xml/bind/JAXBContext;
>>
>> I noticed that TomEE uses an endorsed version 2.2 of JAXB,
>> with the ContextFinder class excluded, as mentioned here:
>>
>> https://issues.apache.org/jira/browse/TOMEE-145
>>
>> But the JVM version of JAXB does not have any ContextFinder.find()
>> method with the signature in my error message, so something is
>> obviously broken. I also checked the latest release (2.2.5) of
>> JAXB-RI, and there is no such signature there either.
>>
>> When I replaced the endorsed jaxb-api.jar and jaxb-impl.jar with
>> the corresponding jars from JAXB-RI 2.2.5 the error went away,
>> and as far as I can see that did not break anything else.
>>
>> Version info:
>>
>> apache-tomee-plus-1.0.0-beta-3-SNAPSHOT (from May 3)
>> jdk1.6.0_27 (which I think contains JAXB-RI version 2.1.10)
>>
>> --
>> Björn Danielsson
>> Cuspy Code AB
>>
Bug: endorsed JAXB is broken
Hi, I get the following error when I try to use JAXB in my webapp: java.lang.NoSuchMethodError: javax.xml.bind.ContextFinder.find(Ljava/lang/String;Ljava/lang/ClassLoader;Ljava/util/Map;)Ljavax/xml/bind/JAXBContext; I noticed that TomEE uses an endorsed version 2.2 of JAXB, with the ContextFinder class excluded, as mentioned here: https://issues.apache.org/jira/browse/TOMEE-145 But the JVM version of JAXB does not have any ContextFinder.find() method with the signature in my error message, so something is obviously broken. I also checked the latest release (2.2.5) of JAXB-RI, and there is no such signature there either. When I replaced the endorsed jaxb-api.jar and jaxb-impl.jar with the corresponding jars from JAXB-RI 2.2.5 the error went away, and as far as I can see that did not break anything else. Version info: apache-tomee-plus-1.0.0-beta-3-SNAPSHOT (from May 3) jdk1.6.0_27 (which I think contains JAXB-RI version 2.1.10) -- Björn Danielsson Cuspy Code AB
Feedback: Removing non-required WorkContextHandler
Hi, I just tried the latest beta snapshot of tomee-plus, and I noticed there are now quite a lot of these, compared with in the beta2 which I have been running until now: INFO: Removing non-required WorkContextHandler with no context: org.apache.geronimo.connector.work.TransactionContextHandler@5b187658 About a dozen per business transaction, which in my case is two JMS messages and one JPA commit. I assume it's nothing to worry about, just reporting this FYI. Version: apache-tomee-1.0.0-beta-3-20120419.041305-93-plus You guys are truly awesome by the way, many thanks for bringing ActiveMQ-5.6 into the new beta so quickly! -- Björn Danielsson Cuspy Code AB
Re: How do I *send* JMS messages from an MDB?
Problem solved! Thanks AndyG, this did the trick. I compiled a fresh ActiveMQ snapshot (r1327126) and replaced the files from your list, and now everything works. Tried with OpenJPA and EclipseLink, both worked without a glitch. So the bug was in ActiveMQ-5.5.1. -- Björn Danielsson Cuspy Code AB AndyG wrote: > These are the required activemq jars: > > openejb\lib\activeio-core-3.2-20090713.104929-1.jar > openejb\lib\activemq-core-5.6-SNAPSHOT.jar > openejb\lib\activemq-protobuf-1.1.jar > openejb\lib\activemq-ra-5.6-SNAPSHOT.jar > openejb\lib\kahadb-5.6-SNAPSHOT.jar > > > -- > View this message in context: > http://openejb.979440.n4.nabble.com/How-do-I-send-JMS-messages-from-an-MDB-tp4561773p4564896.html > Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: How do I *send* JMS messages from an MDB?
Update I can now reproduce the error in a small test program. All I did was increase the messaging from 2 to 4 messages and fiddle a bit with the JPA code. The fiddling required seems to be different depending on whether I use OpenJPA or EclipseLink. I am beginning to suspect that I might be bitten by this bug, fixed in ActiveMQ 5.6.0: https://issues.apache.org/jira/browse/AMQ-3465 Now I am itching to try a newer ActiveMQ than the bundled one. Is this possible? I naively tried replacing the activemq-core jar but that just gave me "peer did not send his wire format". -- Björn Danielsson Cuspy Code AB
Re: How do I *send* JMS messages from an MDB?
Hi, Thanks for your reassuring reply! I have now written a simple test for this, and of course now the test works. So mea culpa, and now I only have to figure out in what way my application code differs from my 100-line test. I'll post back here again when I find the reason, in case anyone else gets this error "resource is allready being used in transaction" and googles it. -- Björn Danielsson Cuspy Code AB Romain Manni-Bucau wrote: > Hi, > > It should work, can you reproduce it in a uniy test? > Le 16 avr. 2012 16:48, "Bjorn Danielsson" > a écrit : > >> I have problems sending JMS messages from my MDB. This MDB >> listens on a queue and then calls an EJB that updates persistent >> storage. The EJB then sends out a notification to a JMS topic. >> >> All this used to work in GlassFish, but on TomEE-plus I always >> get this error that stops the notification from being sent: >> >> javax.jms.JMSException: The resource is allready being used in transaction >> context. >> >> The error message doesn't specify which resource is the culprit, >> but I guess it means the JMS Session? My EJB uses an injected >> ConnectionFactory, just like in the OpenEJB examples. Shouldn't >> that work also when the EJB is called from an MDB, using one >> big nice container-managed transaction that starts when the >> incoming queue message is received? >> >> Version: apache-tomee-plus-1.0.0-beta-2 >> >> -- >> Björn Danielsson >> Cuspy Code AB >>
How do I *send* JMS messages from an MDB?
I have problems sending JMS messages from my MDB. This MDB listens on a queue and then calls an EJB that updates persistent storage. The EJB then sends out a notification to a JMS topic. All this used to work in GlassFish, but on TomEE-plus I always get this error that stops the notification from being sent: javax.jms.JMSException: The resource is allready being used in transaction context. The error message doesn't specify which resource is the culprit, but I guess it means the JMS Session? My EJB uses an injected ConnectionFactory, just like in the OpenEJB examples. Shouldn't that work also when the EJB is called from an MDB, using one big nice container-managed transaction that starts when the incoming queue message is received? Version: apache-tomee-plus-1.0.0-beta-2 -- Björn Danielsson Cuspy Code AB
Re: JMS and peristent messages
Jacek Laskowski wrote:
> On Fri, Sep 23, 2011 at 8:04 PM, Bjorn Danielsson
> wrote:
>> Yet again, ${openejb.base} doesn't work
>
> What's the version of openejb? Would you mind upgrading when a patched
> version comes out?
My results are with 3.2.0-SNAPSHOT from 20110920.
I don't know about the original poster, but I don't mind upgrading
since I am already running a pre-release.
--
Bjorn Danielsson
Cuspy Code AB
Re: JMS and peristent messages
Update:
I wrote:
> You don't get JDBC persistence unless ActiveMQ is explicitly
> configured for that. I guess an "xbean:" URI is needed for
> that, but I haven't tried this myself.
OK, now I have tried.
It turns out that using an "xbean:" URI for BrokerXmlConfig
requires adding Spring libraries to OpenEJB in order to work.
But there is a third alternative, the "properties:" URI.
Unfortunately the ActiveMQ documentation is hard to penetrate,
I had to find javadocs and do some trial and error in order
to figure out which properties are (or might be) available.
Here is the configuration I ended up with. First, openejb.xml:
BrokerXmlConfig properties:file:/opt/openejb/conf/activemq.properties
I tried using ${openejb.base} in the file path, but that didn't
work. Don't know if that is a bug or a candidate for a feature
request :-)
Then I created the file activemq.properties:
useJmx = false
persistent = true
dataDirectory = /opt/openejb/data/activemq
transportConnectorURIs = tcp://localhost:61616
Yet again, ${openejb.base} doesn't work, or rather it results
in a directory with the literal name "${openejb.base}" being
created in the currently connected directory when openejb is
started. I would assume that string interpolation in this file
most likely needs code changes in the ActiveMQ source.
The persistent JMS storage will be a KahaDB database under the
"dataDirectory". I have verified that it actually does persist
and retransmit messages that were sent before a restart and
consumed afterwards. This works for me. I don't know how to
achieve JDBC persistence.
--
Bjorn Danielsson
Cuspy Code AB
Re: JMS and peristent messages
Markus Lutum wrote: > > I have a question how I can get a JMS Message persistent in the Database. > > I am using the following configuration: > (default I think) >[...] > > # Broker configuration URI as defined by ActiveMQ > # see http://activemq.apache.org/broker-configuration-uri.html > #BrokerXmlConfig xbean:file:conf/activemq.xml > BrokerXmlConfig > broker:(tcp://localhost:61616)?useJmx=false&persistent=true >[...] I looked into this since I also want persistant JMS. I found that there is some code in BrokerServer.java (openejb-3.1.x branch) which intercepts a "broker:" URI and runs some special code in that case. Not sure exactly what the code does, but it stops JMS persistence from working. I found that if you let the BrokerXmlConfig property be an empty string, then ActiveMQ will use its default configuration which persists JMS messages by logging them in a KahaDB database under the directory "activemq-data" which is automatically created when ActiveMQ is initialized. You don't get JDBC persistence unless ActiveMQ is explicitly configured for that. I guess an "xbean:" URI is needed for that, but I haven't tried this myself. -- Bjorn Danielsson Cuspy Code AB
Re: OpenEJB 3.2 availability question
David Blevins wrote: > > Anyway, I spent a couple hours last night and got 3.2 build. > I didn't managed to get a 'mvn release:prepare -DdryRun=true' > to work. Some help with that would be amazing. > > I pushed some binaries as well: Many thanks for this! I just confirmed that the new 3.2.0 snapshot works in my project, both standalone and the Tomcat war plugin. The only change needed was to update the api jars in my client. Works like a charm now. Thanks once again. I wish I could help improve the build processes, but Maven and I don't get along very well :-( -- Bjorn Danielsson Cuspy Code AB
Re: OpenEJB 3.2 availability question
Marius Kruger wrote: > > I assume that the guys are more focussed on the 4.0.0 release ATM and > don't really get around to 3.2.0. Yes, that is my impression too when I read the "dev" mailing list archives. The 3.2.x branch seems to be broken. But I thought maybe it's possible to backport the annotation scanning fixes to 3.1.4? And then I noticed that the 3.1.x branch didn't end with the 3.1.4 release. There are commits in that branch as late as March 2011. So I tried checking out and compiling the latest revision from the 3.1.x branch. And it solved my problem completely. It has the exclude/include mechanism that I needed for annotation scanning, and it provides a Tomcat plugin that works with Tomcat 6.0.29, which is the Tomcat version I am constrained to use by the huge third-party application I am integrating my EJB code into. The 3.1.x binaries I compiled called themselves 3.1.5-SNAPSHOT. Maven aborted after 40 minutes due to a missing file while running some test, but the compilation itself got through without errors, and the resulting openejb.war seems to work perfectly. -- Bjorn Danielsson Cuspy Code AB
Re: OpenEJB 3.2 availability question
Jean-Louis MONTEIRO wrote:
>
> Adding the snapshot repository and specifying 3.2.0-SNAPSHOT instead of
> 3.2-SNAPSHOT is enough.
> Then, the magic will appear and Maven will provide you with the latest
> snapshot deployed.
The only thing that 3.2.0-SNAPSHOT provides is the pom file. I was
wondering if there is a way to automatically download and compile
everything given that pom file. I tried this:
mvn -f openejb-3.2.0-20110819.150103-5.pom install
but that didn't work (missing child modules). And since I don't
have a PhD in Mavenology, I gave up.
I also tried replacing the string 3.2-SNAPSHOT with 3.2.0-SNAPSHOT
in all 132 XML files in the openejb-3.2.x-TomcatIntegration branch
and then compiling with mvn, but that resulted in exactly the same
broken openwebbeans depencies as I mentioned in my earlier mail on
Aug 29.
And before all this I deleted my ~/.m2 and installed a profile
with the snapshot repository to ${maven.home}/conf/settings.xml
and verified that the profile is active.
So what am I doing wrong?
--
Bjorn Danielsson
Cuspy Code AB
Re: OpenEJB 3.2 availability question
Marius Kruger wrote: > On 29 August 2011 17:13, Bjorn Danielsson > wrote: >> Is there an OpenEJB 3.2 binary snapshot available anywhere? > > If you use maven the easiest is to add the following repository: > http://repository.apache.org/content/groups/snapshots/ > > You can also browse that url to see all the available binaries. Thanks! I already found a 4.0.0 binary there, but no 3.2.x. I did find a POM file there: openejb-3.2.0-20110819.150103-5.pom. Can I use that to compile it from some working Subversion revision? What would be the magic mvn command to accomplish that? -- Bjorn Danielsson Cuspy Code AB
OpenEJB 3.2 availability question
Is there an OpenEJB 3.2 binary snapshot available anywhere? What I am looking for specifically is an OpenEJB plugin that works with Tomcat 6.0.29 and which has a working include/exclude mechanism for annotation scanning. The exclude mechanism doesn't seem to work in the 3.1.4 plugin, and when I tried a 4.0.0 snapshot it didn't play along with Tomcat 6.0.29, because calls were made to a method that only exists in Tomcat 7: org.apache.catalina.core.StandardContext.addApplicationEventListener. I also tried to compile 3.2 from the Subversion branch, but I ran into problems with broken openwebbeans dependencies which I couldn't figure out how to fix. I am trying to integrate my own EJB-based code with a third-party application that runs on Tomcat 6.0.29, so using Tomcat 7 is not an option at the moment. The plugin from the OpenEJB 3.1.4 release actually works, but I need to add an extra gig of RAM to the server just in order to get through the annotation-scanning phase, which even then takes quite a long time. Running my EJBs in the standalone container in its own JVM works too of course, but for production it would be much nicer to have everything deployed in Tomcat. -- Björn Danielsson Cuspy Code AB
