Nabble - jencks - user

XaPooledConnectionFactory JNDI Set Up

2009-10-01T05:18:40Z

Hi

I am trying to set up XaPooledConnectionFactory as a JNDI resource rather than defining it in Spring. Hibernate Search uses JNDI to look up jms connection factory. Normal connection factory works fine but XA doesnt. The following provides what i'm trying to do:

<Resource name="jms/xaConnectionFactory" auth="Container" type="org.jencks.amqpool.XaPooledConnectionFactory"
description="JMS xa Connection Factory" factory="org.apache.activemq.jndi.JNDIReferenceFactory"
brokerURL="tcp://localhost:5000?trace=true" brokerName="LocalActiveMQBroker"
transactionManager="UserTransaction"/>

in my context.xml file. UserTransaction is jndi defined as well. I know I'm doing something wrong but I'm not sure. Any help would be highly appreciated.

Cheers
Amin

openjpa,jencks,spring configuration...

2009-08-25T09:24:57Z

hi all,
how do I configure jencks 2.2 + openjpa 1.2.1+spring 2.5.6 ? I'm going to use jta outside of container...

looking at http://jencks.codehaus.org/Outbound+JDBC
I was trying to use this config:

<beans>



<bean id="transactionManager" class="org.jencks.factory.TransactionManagerFactoryBean"/>



<bean id="connectionManager" class="org.jencks.factory.ConnectionManagerFactoryBean">
<property name="transactionManager" ref="transactionManager"/>
</bean>



<bean id="jdbcManagedConnectionFactory" class="org.jencks.tranql.DataSourceMCF">
<property name="driverName" value="org.hsqldb.jdbcDriver"/>
<property name="url" value="jdbc:hsqldb:."/>
<property name="user" value="sa"/>
<property name="password" value=""/>
</bean>



<bean id="dataSource" class="org.jencks.factory.ConnectionFactoryFactoryBean">
<property name="managedConnectionFactory" ref="jdbcManagedConnectionFactory"/>
<property name="connectionManager" ref="connectionManager"/>
</bean>

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />

<property name="persistenceXmlLocation" value="file:persistence.xml" />

<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.OpenJpaVendorAdapter">
<property name="showSql" value="true" />
<property name="generateDdl" value="true" />
<property name="database" value="MYSQL" />
</bean>
</property>

<property name="jpaDialect">
<bean class="org.springframework.orm.jpa.vendor.OpenJpaDialect"/>
</property>

</bean>

</beans>

but in unit test , which extends AbstractJpaTests and which worked before with
org.springframework.orm.jpa.JpaTransactionManager, transactions are not commited.

is it correct way to configure entityManagerFactory?

and my persistence.xml:

<persistence-unit name="test1" >

<class>myclass</class>

<exclude-unlisted-classes/>

</persistence-unit>

thanks,
Alex.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Maven release for 2.x?

2009-03-27T00:21:52Z

Thanks for the reply! I'll use this repository.

gnodet wrote:

You'll find everything in the central maven repository:
http://repo2.maven.org/maven2/org/jencks/
The 2.1 release has been out since a long time, I guess that the web
site has not been updated since a long time.

2009/3/26 hbf <fischerk@inf.ethz.ch>:
>
> Dear list,
>
> I am interested in using Jencks but can only see dated versions in public
> maven repositories. For instance, at
>
> http://mvnrepository.com/artifact/jencks/jencks
>
> the latest release is 1.1.3 although the Jencks homepage lists 2.0 (and this
> mailing list mentions 2.1) as the latest release.
>
> Is 2.1 official?
>
> Can one expect a Maven release? (Or was this somebody else who did these
> Maven releases?)
>
> Thanks,
> Hbf
> --
> View this message in context: http://www.nabble.com/Maven-release-for-2.x--tp22732091p22732091.html
> Sent from the jencks - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Maven release for 2.x?

2009-03-26T16:16:04Z

You'll find everything in the central maven repository:
http://repo2.maven.org/maven2/org/jencks/
The 2.1 release has been out since a long time, I guess that the web
site has not been updated since a long time.

2009/3/26 hbf <fischerk@...>:

>
> Dear list,
>
> I am interested in using Jencks but can only see dated versions in public
> maven repositories. For instance, at
>
> http://mvnrepository.com/artifact/jencks/jencks
>
> the latest release is 1.1.3 although the Jencks homepage lists 2.0 (and this
> mailing list mentions 2.1) as the latest release.
>
> Is 2.1 official?
>
> Can one expect a Maven release? (Or was this somebody else who did these
> Maven releases?)
>
> Thanks,
> Hbf
> --
> View this message in context: http://www.nabble.com/Maven-release-for-2.x--tp22732091p22732091.html
> Sent from the jencks - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Maven release for 2.x?

2009-03-26T15:06:37Z

Dear list,

I am interested in using Jencks but can only see dated versions in public maven repositories. For instance, at

http://mvnrepository.com/artifact/jencks/jencks

the latest release is 1.1.3 although the Jencks homepage lists 2.0 (and this mailing list mentions 2.1) as the latest release.

Is 2.1 official?

Can one expect a Maven release? (Or was this somebody else who did these Maven releases?)

Thanks,
Hbf

notification of a connection error while connecting to MOM

2009-03-02T08:46:16Z

I'm writting an application using jencks and I was trying to figure out lately how to be notified that the connection to the middleware went wrong (before to start the consumption). Does anyone knows how I could achieve something like this ? thanks in advance
regards

Re: Following example with Spring's SessionAwareMessageListener

2008-12-02T09:12:59Z

On Tue, Dec 2, 2008 at 3:56 AM, Todd Nine <todd.nine@...> wrote:
> Hi all,
> I'm writing a quick app for testing MDP's with Spring 2.5, Active MQ
> 5.2.0, and Jencks 2.1. I've used the spring context and the MessageListener
> below. I'd like to utilize the SessionAwareMessageListener interface in
> Spring so I can have access to the session object. Is there a way to
> configure this with spring and Jencks? I can't seem to find any
> documentation on what I need, so any help would be appreciated.

I think that is really a Spring question...
Your listener is obtained from a bean factory, in
org.jencks.DefaultEndpointFactory:

MessageListener messageListener = (MessageListener)
beanFactory.getBean(ref, MessageListener.class);

You have to find out how/when Spring applies its bean factory post processors.
Maybe you have to make your listener instantiate eagerly (not lazy).

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Following example with Spring's SessionAwareMessageListener

2008-12-01T17:56:46Z

Hi all,
I'm writing a quick app for testing MDP's with Spring 2.5, Active MQ 5.2.0, and Jencks 2.1. I've used the spring context and the MessageListener below. I'd like to utilize the SessionAwareMessageListener interface in Spring so I can have access to the session object. Is there a way to configure this with spring and Jencks? I can't seem to find any documentation on what I need, so any help would be appreciated.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

    <context:annotation-config />
    <context:component-scan
        base-package="com.onwebconsulting.messaging" />

    <context:property-placeholder location="file:${properties-file}" />

    <bean id="jencks" class="org.jencks.JCAContainer">
        <property name="threadPoolSize" value="25" />
        <property name="transactionManager" ref="transactionManager" />

        
        <property name="resourceAdapter">
            <bean id="activeMQResourceAdapter"
                class="org.apache.activemq.ra.ActiveMQResourceAdapter">
                <property name="serverUrl" value="${mq.broker.url}" />
            </bean>
        </property>
    </bean>

    <bean id="inboundConnectorA" class="org.jencks.JCAConnector">
        <property name="jcaContainer" ref="jencks" />

        
        <property name="activationSpec">
            <bean
                class="org.apache.activemq.ra.ActiveMQActivationSpec">
                <property name="destination" value="${mq.queue.name}" />
                <property name="destinationType"
                    value="javax.jms.Queue" />
            </bean>
        </property>

        <property name="transactionManager" ref="transactionManager"></property>

        <property name="ref" value="listener" />
    </bean>

    <bean id="transactionManager"
        class="org.jencks.factory.TransactionManagerFactoryBean" />

</beans>

Listener class

package com.onwebconsulting.messaging.reader.jms;

import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.Session;
import javax.jms.TextMessage;

import org.springframework.jms.listener.SessionAwareMessageListener;
import org.springframework.stereotype.Service;

import com.onwebconsulting.messaging.reader.MessageReceiver;

/**
*
* @author Todd Nine
*
*/
@Service("listener")
public class TextMessageReceiver implements MessageListener,
        SessionAwareMessageListener, MessageReceiver {

    /*
    * (non-Javadoc)
    *
    * @see org.springframework.jms.listener.SessionAwareMessageListener#onMessage(javax.jms.Message,
    *      javax.jms.Session)
    */
    public void onMessage(Message message, Session session) throws JMSException {

        if (!(message instanceof TextMessage)) {
            session.rollback();
            return;
        }

        TextMessage txtMessage = (TextMessage) message;

        receiveMessage(txtMessage.getText());

    }

    /*
    * (non-Javadoc)
    *
    * @see com.onwebconsulting.messaging.reader.MessageReceiver#receiveMessage(java.lang.String)
    */
    public void receiveMessage(String inputMessage) {
        System.out.println(inputMessage);

    }

    public void onMessage(Message message) {

        if (!(message instanceof TextMessage)) {
            throw new RuntimeException("Incorrect message type");
        }

        TextMessage txtMessage = (TextMessage) message;

        try {
            receiveMessage(txtMessage.getText());
        } catch (JMSException e) {
            throw new RuntimeException(e);
        }

    }

}

Thanks,
Todd

Re: Dependencies/Example help

2008-09-12T04:43:22Z

try:

activeio-core-3.0.0-incubator.jar
activemq-console-4.1.1.jar
activemq-core-4.1.1.jar
activemq-core-4.1.1-tests.jar
activemq-jaas-4.1.1.jar
activemq-ra-4.1.1.jar
activemq-web-4.1.1.jar
backport-util-concurrent-2.1.jar
commons-logging-1.1.jar
geronimo-connector-1.2-beta.jar
geronimo-j2ee-connector_1.5_spec-1.0.1.jar
geronimo-j2ee-management_1.0_spec-1.0.jar
geronimo-jms_1.1_spec-1.0.jar
geronimo-jta_1.0.1B_spec-1.0.1.jar
geronimo-transaction-1.2-beta.jar
jencks-2.0-all.jar
jencks-amqpool-2.0.jar
log4j-1.2.12.jar
mx4j-2.1.1.jar
spring-2.0.jar

ckeeling wrote:

I apologize upfront if this request is too elementary.

I am trying to get a simple proof of concept to work using Spring, Jencks, ActiveMQ and Tomcat. At this point, I would be happy to be able to consume a message from an ActiveMQ topic from within the spring application. To date, I have been unable to claim any success with getting this to deploy and run.

I have the ActiveMQ broker starting from the spring context. I also have a messagelistener.

I guess my lack of insight is preventing my progress... I'm using jencks-2.0-all.
After tracking down missing class definitions and guessing at where to pull them from, I have the following jars in the classpath:
geronimo-connector-2.0.1.jar
geronimo-j2ee-management_1.0_spec-1.0.jar
geronimo-jms_1.1_spec-1.0.jar
geronimo-jta_1.1_spec-1.1.jar
geronimo-transaction-2.0.1.jar
aopalliance.jar

I'm using the 'simple' from http://jencks.org/Message+Driven+POJOs for configuration.

Is there some magic list of external jars/version that I need to obtain to get this functional.

My current roadblock is listed below.

Any assistance is greatly appreciated.

- Thanks, Curt

Caused by:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'transactionManager': FactoryBean threw exception on object creation; nested exception is java.lang.NoSuchMethodError: org.apache.geronimo.transaction.manager.GeronimoTransactionManager.<init>(ILorg/apache/geronimo/transaction/manager/XidFactory;Lorg/apache/geronimo/transaction/manager/TransactionLog;Ljava/util/Collection;)V
Caused by:
java.lang.NoSuchMethodError: org.apache.geronimo.transaction.manager.GeronimoTransactionManager.<init>(ILorg/apache/geronimo/transaction/manager/XidFactory;Lorg/apache/geronimo/transaction/manager/TransactionLog;Ljava/util/Collection;)V
at org.jencks.GeronimoPlatformTransactionManager.<init>(GeronimoPlatformTransactionManager.java:72)
at org.jencks.factory.TransactionManagerFactoryBean.getObject(TransactionManagerFactoryBean.java:55)
at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectFromFactoryBean(AbstractBeanFactory.java:1211)
at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1177)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:207)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:245)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:124)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1019)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:809)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346)
at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156)
at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3763)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4211)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:904)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:867)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
at org.apache.catalina.core.StandardService.start(StandardService.java:450)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)

need help with configuration

2008-08-18T13:53:43Z

Hi,
I'm currently developing a JCA adapter using Apache Geronimo 2.1. However, I need to run it on an IBM WebSphere which proved to be a major classloading nightmare. (Need some 3rd party libs that clash with WebSphere versions).
Therefore I try to evaluate Jencks as alternative to move the adapter to a WAR so that I can activate the protection classloader in WS.
So I have setup a new maven project depending on the JAR of the RAR project and on Jencks 2.1 plus Spring 2.5.5.

I use the following application.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
>

<bean id="transactionManager" class="org.jencks.factory.TransactionManagerFactoryBean" />

<bean id="connection-manager" class="org.jencks.factory.ConnectionManagerFactoryBean">
<property name="transactionManager" ref="transactionManager"></property>
</bean>



<bean id="abcd-resource-adapter" class="com.example.ResourceAdapterImpl">
<property name="some" value="value"></property>
</bean>

<bean id="con-factory-factory-bean" class="org.jencks.factory.ConnectionFactoryFactoryBean">
<property name="managedConnectionFactory" ref="CONN"></property>
<property name="connectionManager" ref="connection-manager"></property>
</bean>

<bean id="CONN" class="com.example.ManagedConnectionFactoryImpl">
<property name="some.other" value="value"></property>
<property name="resourceAdapter" ref="abcd-resource-adapter"></property>
</bean>

</beans>

Now, when starting this as a standalone application like

ApplicationContext ctxt = new ClassPathXmlApplicationContext("application.xml");

The ManagedConnectionFactoryImpl throws an exception on setRessourceAdapter() (from interface RessourceAdapterAssociation):
Caused by: java.lang.ClassCastException: java.lang.NoClassDefFoundError cannot be cast to java.lang.Exception

More details: the resource adapter internally uses a picocontainer and the setResourceAdapter() method attaches a child container and starts the child container. The exception occurs on starting the child container.

Now, the exception looks like a classloader problem to me. Just that I don't understand which classloader interact here, mind that this is stand alone - no JEE container involved.

Second, is the configuration correct?

One or many connection managers?

2008-07-24T17:01:40Z

I'm learning Jencks and trying to set up a simple JMS in -> JDBC save -> JMS out mechanism and enclose it all in one XA transaction. i.e. I pull a TextMessage off a queue, save the text to a database, and send a new message to another queue. I'm making pretty good progress, but I've encountered an odd-seeming problem. I'm getting this exception when I try to do the "JMS out" part:

java.lang.ClassCastException: org.tranql.connector.jdbc.ConnectionHandle cannot be cast to javax.jms.Connection
at org.apache.activemq.ra.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:94)
at org.apache.activemq.ra.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:67)
at org.springframework.jms.support.JmsAccessor.createConnection(JmsAccessor.java:184)
at org.springframework.jms.core.JmsTemplate.access$500(JmsTemplate.java:90)
at org.springframework.jms.core.JmsTemplate$JmsTemplateResourceFactory.createConnection(JmsTemplate.java:1030)
at org.springframework.jms.connection.ConnectionFactoryUtils.doGetTransactionalSession(ConnectionFactoryUtils.java:280)
at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:458)
at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:539)
at rds.jencks.ListenerBean.onMessage(ListenerBean.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy0.onMessage(Unknown Source)
at org.jencks.XAEndpoint.onMessage(XAEndpoint.java:129)
at org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:116)
at org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:59)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:727)
at org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:165)
at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:290)
at org.apache.geronimo.connector.work.pool.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)

Tracing through the Geronimo code that Jencks is using, I see that when the org.apache.activemq.ra.ActiveMQConnectionFactory calls connectionManager.allocateConnection()--that's line 94, where the exception occurs--it makes its way down to a org.apache.geronimo.connector.outbound.TransactionCachingInterceptor that seems to cache connections by transaction. This interceptor returns a previously-cached *JDBC* connection that was associated with the same transaction. That obviously won't work for a JMS producer.

I assume this is happening because I'm using the same connection manager object for both JMS and JDBC resources. I assumed this was the right thing to do because of how JCA is set up. Am I supposed to create a separate connection manager for each resource adapter/connection factory, or have I failed to configure something else properly?

Re: JcaPooledConnectionFactory source unavailable

2008-06-03T15:14:48Z

You can check it out from SVN at http://svn.codehaus.org/jencks/.

...or view it directory here.

JcaPooledConnectionFactory source unavailable

2008-06-03T04:48:31Z

The source of the jencks-amqpool code is unavailable. The link doesn't work. I suppose that gnodet is the author. Where can I find the code?
http://fisheye.codehaus.org/browse/jencks/trunk/jencks-amqpool/src/main/java/org/jencks/amqpool/JcaPooledConnectionFactory.java

I am testing the performance of the JMSTemplate + JcaPooledConnectionFactory +ActiveMQ vs. Raw client code (1 connection and 1 session used) but it is even to 10 times slower (when using vm:// transport).

I debuged the source (Spring 2.0.8 - JMSTemplate) there are some invocations which could cause the overhead (especially in the "execute" method - line 409 http://kickjava.com/src/org/springframework/jms/core/JmsTemplate.java.htm), the connections and sessions are there created -> the underlying pool (jencks-amqpool) does the pooling - but I haven't seen the code so I can't find the bottleneck...

I don't want to write the pooling myself... Any clues how to use the JcaPooledConnectionFactory efficiently (maybe without JMSTemplate)...

Regards,
Tomek

My IT Blog: http://www.tomek.bujok.info

Re: Inbound MDP - multiple connection threads in a pool

2008-06-03T00:52:24Z

My question is still relevant...

How to configure the outbound connection pool = make the JCA Container to use many connections to the ActiveMQ broker for one Message Driven Pojo

I think I have it wrongly configured, this part of my configuration is not referenced in any other bean: <bean id="AMQconnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"/>

<bean id="connectionFactory" class="org.jencks.amqpool.JcaPooledConnectionFactory">
<constructor-arg value="vm://localhost" />
<property name="connectionFactory" ref="AMQconnectionFactory" />
<property name="maxConnections" value="8" />
<property name="maximumActive" value="8" />
<property name="transactionManager" ref="transactionManager"/>
<property name="name" value="LocalBroker"/>
</bean>

So I am actually sure that I can remove it... ActiveMQActivationSpec -> it configures number of sessions per connection... but how to configure the outbound connection pool = make the JCA Container to use many connections to the ActiveMQ broker for one Message Driven Pojo (one queue)

-

My IT Blog: http://www.tomek.bujok.info

Re: Outbound session pooling - number of sessions per connection

2008-06-03T00:45:52Z

Ok, this is my mistake, I read the documentation so many times, that I missed this:


<property name="maxConnections" value="8" />


<property name="maximumActive" value="250" />

My IT Blog: http://www.tomek.bujok.info

Outbound session pooling - number of sessions per connection

2008-06-02T09:30:47Z

I have configured connection pooling using JmsTemplate and org.jencks.amqpool.JcaPooledConnectionFactory.
How can I set number of sessions for one connection???

This is my configuration:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>

<bean id="transactionManager" class="org.jencks.factory.TransactionManagerFactoryBean"/>

<bean id="connectionFactory"
class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="tcp://localhost:7777" />
</bean>


<bean id="JcaPooledConnectionFactory" class="org.jencks.amqpool.JcaPooledConnectionFactory">

<property name="connectionFactory" ref="connectionFactory" />
<property name="maxConnections" value="8" />
<property name="maximumActive" value="8" />
<property name="transactionManager" ref="transactionManager"/>
<property name="name" value="LocalBroker"/>
</bean>

<bean id="jmsTemplate"
class="org.springframework.jms.core.JmsTemplate">
<property name="defaultDestinationName" value="Hello.Queue"/>
<property name="connectionFactory" ref="JcaPooledConnectionFactory"/>


<property name="sessionTransacted" value="true"/>

</bean>

</beans>

Thanks

My IT Blog: http://www.tomek.bujok.info

Inbound MDP - multiple connection threads in a pool

2008-06-02T06:36:12Z

Hi,

I read a blog about configuring a pool of connections (inbound): http://gnodet.blogspot.com/2006/12/over-past-weeks-i-spend-some-times-load.html

I am using Spring+Jencks(2.1)+ActiveMQ(4.1.1).
I would like to use JcaPooledConnectionFactory (with jencks JCA inbound support).

I configured the org.jencks.amqpool.JcaPooledConnectionFactory , but it doesn't seem to work, there is only one connection and multiple sessions.

Here is my configuration:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>

<bean id="broker" class="org.apache.activemq.xbean.BrokerFactoryBean">
<property name="config" value="classpath:broker.xml" />
</bean>

<bean id="transactionManager" class="org.jencks.factory.TransactionManagerFactoryBean"/>

<bean id="resourceAdapter" class="org.apache.activemq.ra.ActiveMQResourceAdapter" depends-on="broker">
<property name="serverUrl" value="vm://localhost"/>
</bean>

<bean id="AMQconnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"/>

<bean id="connectionFactory" class="org.jencks.amqpool.JcaPooledConnectionFactory">
<constructor-arg value="vm://localhost" />
<property name="connectionFactory" ref="AMQconnectionFactory" />
<property name="maxConnections" value="8" />
<property name="maximumActive" value="8" />
<property name="transactionManager" ref="transactionManager"/>
<property name="name" value="LocalBroker"/>
</bean>

<bean id="jencks" class="org.jencks.JCAContainer">
<property name="transactionManager" ref="transactionManager"/>
<property name="threadPoolSize" value="25"/>
<property name="resourceAdapter" ref="resourceAdapter"/>
</bean>

<bean id="activspec" class="org.apache.activemq.ra.ActiveMQActivationSpec">
<property name="destination" value="Hello.Queue"/>
<property name="destinationType" value="javax.jms.Queue"/>
<property name="enableBatch" value="true" />
<property name="maxMessagesPerBatch" value="1" />
<property name="maxSessions" value="25" />
</bean>

<bean id="inboundConnector" class="org.jencks.JCAConnector">
<property name="jcaContainer" ref="jencks" />
<property name="activationSpec" ref="activspec"/>
<property name="ref" value="echoBean"/>
</bean>

<bean id="echoBean" class="mdpojo.approach.activemq.HelloBean" singleton="true"/>
</beans>

I read a post: http://www.nabble.com/How-to-configure-multiple-connection-threads-tt15447114.html#a15447114
Does it actually work? I am not able to check it - logs are all the time the same...

So the only way to do it is to copy/paste the inboundConnector??? It doesn't seem to be a good practice... What if I would like to have 20 inbound-connection pool?

My IT Blog: http://www.tomek.bujok.info

Re: [ANNOUNCE] Jencks 2.1 released

2008-05-27T09:12:17Z

Jenks is available from the maven public repositories:
http://repo1.maven.org/maven2/org/jencks/jencks/2.1/
The tar.gz archive will contain the needed dependencies if you use the
provided jencks-all jar, else you'll need the geronimo transaction
manager and jca connector as mentioned by Andrei.

On Tue, May 27, 2008 at 3:30 PM, kapilok <kapilok@...> wrote:

>
> Please send the link for download and the list of jar dependencies required.
>
> Thanks,
> Kapil
>
>
> gnodet wrote:
>>
>> Jencks 2.1 has just been released and should be available on the public
>> repos soon.
>> This release mainly consist in upgrading to Geronimo 2.0.x components for
>> the transaction manager and connector.
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>>
>>
>
> --
> View this message in context: http://www.nabble.com/-ANNOUNCE--Jencks-2.1-released-tp13093918p17490499.html
> Sent from the jencks - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: [ANNOUNCE] Jencks 2.1 released

2008-05-27T08:20:32Z

On 5/27/08, kapilok <kapilok@...> wrote:

Download Geronimo: http://geronimo.apache.org/apache-geronimo-v211-release.html
and you will find in there geronimo-jta_1.1_spec-1.1.1.jar
or...
http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-jta_1.1_spec/1.1.1
You can deduce from the url the needed maven config...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: [ANNOUNCE] Jencks 2.1 released

2008-05-27T06:30:39Z

Please send the link for download and the list of jar dependencies required.

Thanks,
Kapil

gnodet wrote:

Jencks 2.1 has just been released and should be available on the public
repos soon.
This release mainly consist in upgrading to Geronimo 2.0.x components for
the transaction manager and connector.

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

Jencks2.0 jar dependencies

2008-05-27T06:17:42Z

Does anyone have a list of jar dependencies for jencks2.0 ? Or a maven project example that compiles ?
I am using Jencks2.0 + ActiveMQ4.1.1 + Spring2.0
I have tried the jars in the download and the suggestions on this forum, but continue to get NoClassDefFoundError. I fixed a few by trial and error, but I'm still stuck with
java.lang.NoClassDefFoundError: javax/transaction/TransactionSynchronizationRegistry

Here is my eclipse classpath
<classpathentry kind="lib" path="C:/apache-activemq-4.1.1/apache-activemq-4.1.1.jar"/>
<classpathentry kind="lib" path="C:/spring-framework-2.0.3/dist/spring.jar"/>
<classpathentry kind="lib" path="C:/spring-framework-2.0.3/lib/junit/junit.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/optional/xbean-spring-2.8.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/optional/backport-util-concurrent-2.1.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/optional/commons-logging-1.0.4.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/optional/log4j-1.2.9.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/optional/tranql-connector-1.1.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/optional/xapool-without-pool-1.4.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/activemq-ra-4.1.1.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/jencks-2.0-all.zip"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/geronimo-transaction-2.0.2.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/geronimo-connector-2.0.2.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/geronimo-j2ee-connector_1.5_spec-1.0.1.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/geronimo-j2ee-management_1.0_spec-1.0.1.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/geronimo-jms_1.1_spec-1.0.jar"/>
<classpathentry kind="lib" path="C:/jencks-2.0/lib/geronimo-jta_1.0.1B_spec-1.0.1.jar"/>

Please help.
Thanks,
Kapil

Re: Jencks Message driven POJOS threads left running after ctx.destroy

2008-03-07T12:51:09Z

Hi Guillaume, have you had a chance to review the code changes? Thx, Jerry

On Sun, Mar 2, 2008 at 8:34 AM, Jerry Shea <jerry.shea@...> wrote:

Tidied version of code attached (shutdownThreads.patch).

What I meant to say in that last email was that I didn't touch WorkManagerFactoryBean although it does create a thread pool in some circumstances. I've had a look at that again now and have attached another patch (shutdownThreadsWMFB.patch).

cheers, Jerry

On Sat, Mar 1, 2008 at 9:40 PM, Jerry Shea <jerry.shea@...> wrote:

JIRA does not appear to be up - code attached. I didn't touch although I guess this should use a JencksWorkManager if it creates a thread pool.

Cheers, Jerry

On Thu, Feb 28, 2008 at 7:05 PM, Guillaume Nodet <gnodet@...> wrote:

The project is not dead per se. This is just that the project has
fullfilled its purpose
and is no longer actively developped.
If there is a need for another release, I'll do it.
So please, raise a JIRA and attach a patch, i'll review and apply it.

On Thu, Feb 28, 2008 at 8:31 AM, Andrei Ivanov <andrei.ivanov@...> wrote:
> I think it would be nice if you could open an issue for jencks and
> attach the code there...
> Maybe it will even be included in a next version...
> Hmm... http://jira.goopen.org/jira/browse/JCA seems to be dead...
> Well... kind of like this project...
> Post it here then...
> Thank you.
>
>
>
> On 2/28/08, Jerry Shea <jerry.shea@...> wrote:
> > I have solved my problem by inhertiting from the Geronimo work manager and
> > doing exactly that. Do you want the code?
> >
> >
> >
> > On Thu, Feb 28, 2008 at 12:59 AM, Guillaume Nodet <gnodet@...> wrote:
> >
> > > Well, the code seems ok to me, as the thread pools are given to the
> > > work manager.
> > > So they need to be created and shut down from the one that creates the
> > > work manager.
> > > In the jencks case, i'm not sure who does that (haven't looked yet),
> > > but it should be easy
> > > to fix, maybe by inheriting the geronimo work manager and overriding
> > > doStop if needed.
> > >
> > >
> > >
> > >
> > > On Wed, Feb 27, 2008 at 1:58 PM, Andrei Ivanov <andrei.ivanov@...>
> > wrote:
> > > >
> > http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?view=log
> > > >
> > > > It seems that code was removed in rev 392847:
> > > > Make thread pools manageable and make our WorkManager use our thread
> > pools
> > > > under the covers.
> > > >
> > http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?r1=381272&r2=392847
> > > >
> > > >
> > > >
> > > > On 2/27/08, Jerry Shea <jerry.shea@...> wrote:
> > > > > geronimo-connector-2.1 has the same problem (empty doStop method)
> > > > > unfortunately...
> > > > >
> > > > > I'm having difficulty finding any more info on geronimo-connector.
> > It's even
> > > > > proving difficult to find its subversion repository or maybe its just
> > too
> > > > > late at night ;)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Feb 27, 2008 at 9:03 PM, Guillaume Nodet <gnodet@...>
> > wrote:
> > > > >
> > > > > > Yeah, good idea. Maybe a simple version bump would work ?
> > > > > > Have you tried that, or is there any api changes that we need to
> > deal with
> > > > > ?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Feb 27, 2008 at 11:02 AM, Jerry Shea <jerry.shea@...>
> > wrote:
> > > > > > > It looks like a more recent version of GeronimoWorkMnaager shuts
> > down
> > > > > its
> > > > > > > thread pools in the doStop method - see here:
> > > > > > >
> > > > >
> > http://www.docjar.com/html/api/org/apache/geronimo/connector/work/GeronimoWorkManager.java.html
> > > > > > >
> > > > > > > Are there any plans to upgrade the the version of
> > geronimo-connector
> > > > > that
> > > > > > > Jencks 2.1 depends on? I'm more than happy to assist if needed...
> > > > > > >
> > > > > > > Cheers, Jerry
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Feb 27, 2008 at 8:55 PM, JerryShea <jerry.shea@...>
> > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I've cut and pasted the jencks JCA config from
> > > > > > > > http://jencks.org/Message+Driven+POJOs and if
> > I use
> > > > > it like this:
> > > > > > > > AbstractApplicationContext ctx = new
> > > > > > > ClassPathXmlApplicationContext(new
> > > > > > > > String[] {
> > > > > > > > "/spring-jencks.xml",
> > > > > > > > });
> > > > > > > > Thread.sleep(3000);
> > > > > > > > ctx.destroy();
> > > > > > > >
> > > > > > > > after the spring application context has been created, a number
> > of
> > > > > threads
> > > > > > > > are started up (JCAContainer.afterPropertiesSet creates a
> > Geronimo
> > > > > work
> > > > > > > > manager which in turn creates a thread pool).
> > > > > > > >
> > > > > > > > When ctx.destroy is called, JCAContainer.destroy gets called
> > which in
> > > > > turn
> > > > > > > > calls geronimoWorkManager.doStop() which does... nothing!
> > > > > > > >
> > > > > > > > Shouldn't something be shutting down the thread pool? The
> > threads that
> > > > > are
> > > > > > > > created remain alive and prevent my application from closing
> > down.
> > > > > > > >
> > > > > > > > Thx, Jerry
> > > > > > > >
> > > > > > > > --
> > > > > > > > View this message in context:
> > > > > > >
> > > > >
> > http://www.nabble.com/Jencks-Message-driven-POJOS-threads-left-running-after-ctx.destroy-tp15709825p15709825.html
> > > > > > > > Sent from the jencks - user mailing list archive at Nabble.com.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe from this list, please visit:
> > > > > > > >
> > > > > > > > http://xircles.codehaus.org/manage_email
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > > ------------------------
> > > > > > Blog: http://gnodet.blogspot.com/
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe from this list, please visit:
> > > > > >
> > > > > > http://xircles.codehaus.org/manage_email
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe from this list, please visit:
> > > >
> > > > http://xircles.codehaus.org/manage_email
> > > >

> > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > >
> > >
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--

Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Jencks Message driven POJOS threads left running after ctx.destroy

2008-03-01T13:34:02Z

Tidied version of code attached (shutdownThreads.patch).

What I meant to say in that last email was that I didn't touch WorkManagerFactoryBean although it does create a thread pool in some circumstances. I've had a look at that again now and have attached another patch (shutdownThreadsWMFB.patch).

cheers, Jerry

On Sat, Mar 1, 2008 at 9:40 PM, Jerry Shea <jerry.shea@...> wrote:

JIRA does not appear to be up - code attached. I didn't touch although I guess this should use a JencksWorkManager if it creates a thread pool.

Cheers, Jerry

On Thu, Feb 28, 2008 at 7:05 PM, Guillaume Nodet <gnodet@...> wrote:

The project is not dead per se. This is just that the project has
fullfilled its purpose
and is no longer actively developped.
If there is a need for another release, I'll do it.
So please, raise a JIRA and attach a patch, i'll review and apply it.

On Thu, Feb 28, 2008 at 8:31 AM, Andrei Ivanov <andrei.ivanov@...> wrote:
> I think it would be nice if you could open an issue for jencks and
> attach the code there...
> Maybe it will even be included in a next version...
> Hmm... http://jira.goopen.org/jira/browse/JCA seems to be dead...
> Well... kind of like this project...
> Post it here then...
> Thank you.
>
>
>
> On 2/28/08, Jerry Shea <jerry.shea@...> wrote:
> > I have solved my problem by inhertiting from the Geronimo work manager and
> > doing exactly that. Do you want the code?
> >
> >
> >
> > On Thu, Feb 28, 2008 at 12:59 AM, Guillaume Nodet <gnodet@...> wrote:
> >
> > > Well, the code seems ok to me, as the thread pools are given to the
> > > work manager.
> > > So they need to be created and shut down from the one that creates the
> > > work manager.
> > > In the jencks case, i'm not sure who does that (haven't looked yet),
> > > but it should be easy
> > > to fix, maybe by inheriting the geronimo work manager and overriding
> > > doStop if needed.
> > >
> > >
> > >
> > >
> > > On Wed, Feb 27, 2008 at 1:58 PM, Andrei Ivanov <andrei.ivanov@...>
> > wrote:
> > > >
> > http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?view=log
> > > >
> > > > It seems that code was removed in rev 392847:
> > > > Make thread pools manageable and make our WorkManager use our thread
> > pools
> > > > under the covers.
> > > >
> > http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?r1=381272&r2=392847
> > > >
> > > >
> > > >
> > > > On 2/27/08, Jerry Shea <jerry.shea@...> wrote:
> > > > > geronimo-connector-2.1 has the same problem (empty doStop method)
> > > > > unfortunately...
> > > > >
> > > > > I'm having difficulty finding any more info on geronimo-connector.
> > It's even
> > > > > proving difficult to find its subversion repository or maybe its just
> > too
> > > > > late at night ;)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Feb 27, 2008 at 9:03 PM, Guillaume Nodet <gnodet@...>
> > wrote:
> > > > >
> > > > > > Yeah, good idea. Maybe a simple version bump would work ?
> > > > > > Have you tried that, or is there any api changes that we need to
> > deal with
> > > > > ?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Feb 27, 2008 at 11:02 AM, Jerry Shea <jerry.shea@...>
> > wrote:
> > > > > > > It looks like a more recent version of GeronimoWorkMnaager shuts
> > down
> > > > > its
> > > > > > > thread pools in the doStop method - see here:
> > > > > > >
> > > > >
> > http://www.docjar.com/html/api/org/apache/geronimo/connector/work/GeronimoWorkManager.java.html
> > > > > > >
> > > > > > > Are there any plans to upgrade the the version of
> > geronimo-connector
> > > > > that
> > > > > > > Jencks 2.1 depends on? I'm more than happy to assist if needed...
> > > > > > >
> > > > > > > Cheers, Jerry
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Feb 27, 2008 at 8:55 PM, JerryShea <jerry.shea@...>
> > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I've cut and pasted the jencks JCA config from
> > > > > > > > http://jencks.org/Message+Driven+POJOs and if
> > I use
> > > > > it like this:
> > > > > > > > AbstractApplicationContext ctx = new
> > > > > > > ClassPathXmlApplicationContext(new
> > > > > > > > String[] {
> > > > > > > > "/spring-jencks.xml",
> > > > > > > > });
> > > > > > > > Thread.sleep(3000);
> > > > > > > > ctx.destroy();
> > > > > > > >
> > > > > > > > after the spring application context has been created, a number
> > of
> > > > > threads
> > > > > > > > are started up (JCAContainer.afterPropertiesSet creates a
> > Geronimo
> > > > > work
> > > > > > > > manager which in turn creates a thread pool).
> > > > > > > >
> > > > > > > > When ctx.destroy is called, JCAContainer.destroy gets called
> > which in
> > > > > turn
> > > > > > > > calls geronimoWorkManager.doStop() which does... nothing!
> > > > > > > >
> > > > > > > > Shouldn't something be shutting down the thread pool? The
> > threads that
> > > > > are
> > > > > > > > created remain alive and prevent my application from closing
> > down.
> > > > > > > >
> > > > > > > > Thx, Jerry
> > > > > > > >
> > > > > > > > --
> > > > > > > > View this message in context:
> > > > > > >
> > > > >
> > http://www.nabble.com/Jencks-Message-driven-POJOS-threads-left-running-after-ctx.destroy-tp15709825p15709825.html
> > > > > > > > Sent from the jencks - user mailing list archive at Nabble.com.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe from this list, please visit:
> > > > > > > >
> > > > > > > > http://xircles.codehaus.org/manage_email
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > > ------------------------
> > > > > > Blog: http://gnodet.blogspot.com/
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe from this list, please visit:
> > > > > >
> > > > > > http://xircles.codehaus.org/manage_email
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe from this list, please visit:
> > > >
> > > > http://xircles.codehaus.org/manage_email
> > > >

> > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > >
> > >
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--

Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Index: src/main/java/org/jencks/JencksWorkManager.java
===================================================================
--- src/main/java/org/jencks/JencksWorkManager.java (revision 0)
+++ src/main/java/org/jencks/JencksWorkManager.java (revision 0)
@@ -0,0 +1,36 @@
+package org.jencks;
+
+import java.util.concurrent.Executor;
+import java.util.concurrent.ExecutorService;
+
+import org.apache.geronimo.connector.work.GeronimoWorkManager;
+import org.apache.geronimo.transaction.manager.GeronimoTransactionManager;
+import org.jencks.factory.GeronimoDefaults;
+
+/**
+ * Jencks-specific override of GeronimoWorkManager which takes responsibility for
+ * creating and shutting down its own thread pool.
+ * @author Jerry Shea
+ */
+public class JencksWorkManager extends GeronimoWorkManager {
+
+ private JencksWorkManager(Executor threadPool, GeronimoTransactionManager transactionManager) {
+ super(threadPool, threadPool, threadPool, transactionManager);
+ }
+
+ /**
+ * Public constructor
+ * @param threadPoolSize size of thread pool to create
+ * @param transactionManager
+ */
+ public JencksWorkManager(int threadPoolSize, GeronimoTransactionManager transactionManager) {
+ this(GeronimoDefaults.createThreadPool(threadPoolSize), transactionManager);
+ }
+
+ /**
+ * Override base class implementation to shut down our thread pool
+ */
+ public void doStop() throws Exception {
+ ((ExecutorService)this.getScheduledWorkExecutorPool()).shutdown();
+ }
+}
Index: src/main/java/org/jencks/JencksWorkManager.java
===================================================================
--- src/main/java/org/jencks/JencksWorkManager.java (revision 0)
+++ src/main/java/org/jencks/JencksWorkManager.java (revision 0)
@@ -0,0 +1,39 @@
+package org.jencks;
+
+import java.util.concurrent.ExecutorService;
+
+import org.apache.geronimo.connector.work.GeronimoWorkManager;
+import org.apache.geronimo.transaction.manager.GeronimoTransactionManager;
+import org.jencks.factory.GeronimoDefaults;
+
+/**
+ * Jencks-specific override of GeronimoWorkManager which creates and shuts down its own
+ * thread pool. This ensures that no threads will be left running after an orderly
+ * shutdown of an instance of this class.
+ * @author Jerry Shea
+ */
+public class JencksWorkManager extends GeronimoWorkManager {
+
+ private ExecutorService threadPool;
+
+ private JencksWorkManager(ExecutorService threadPool, GeronimoTransactionManager transactionManager) {
+ super(threadPool, threadPool, threadPool, transactionManager);
+ this.threadPool = threadPool;
+ }
+
+ /**
+ * Public constructor
+ * @param threadPoolSize size of thread pool to create
+ * @param transactionManager
+ */
+ public JencksWorkManager(int threadPoolSize, GeronimoTransactionManager transactionManager) {
+ this((ExecutorService) GeronimoDefaults.createThreadPool(threadPoolSize), transactionManager);
+ }
+
+ /**
+ * Override base class implementation to shut down our thread pool
+ */
+ public void doStop() throws Exception {
+ threadPool.shutdown();
+ }
+}
Index: src/main/java/org/jencks/factory/GeronimoDefaults.java
===================================================================
--- src/main/java/org/jencks/factory/GeronimoDefaults.java (revision 176)
+++ src/main/java/org/jencks/factory/GeronimoDefaults.java (working copy)
@@ -28,12 +28,12 @@
import org.apache.geronimo.connector.outbound.connectionmanagerconfig.PoolingSupport;
import org.apache.geronimo.connector.outbound.connectionmanagerconfig.TransactionSupport;
import org.apache.geronimo.connector.outbound.connectionmanagerconfig.XATransactions;
-import org.apache.geronimo.connector.work.GeronimoWorkManager;
import org.apache.geronimo.transaction.log.UnrecoverableLog;
import org.apache.geronimo.transaction.manager.GeronimoTransactionManager;
import org.apache.geronimo.transaction.manager.TransactionLog;
import org.apache.geronimo.transaction.manager.XidFactory;
import org.apache.geronimo.transaction.manager.XidFactoryImpl;
+import org.jencks.JencksWorkManager;
import org.springframework.beans.FatalBeanException;

/**
@@ -78,8 +78,7 @@
}

public static WorkManager createWorkManager(GeronimoTransactionManager transactionManager, int threadPoolSize) {
- Executor threadPool = createThreadPool(threadPoolSize);
- WorkManager geronimoWorkManager = new GeronimoWorkManager(threadPool, threadPool, threadPool, transactionManager);
+ WorkManager geronimoWorkManager = new JencksWorkManager(threadPoolSize, transactionManager);
return geronimoWorkManager;
}

Index: D:/Development/jencks/src/main/java/org/jencks/JencksWorkManager.java
===================================================================
--- D:/Development/jencks/src/main/java/org/jencks/JencksWorkManager.java (revision 0)
+++ D:/Development/jencks/src/main/java/org/jencks/JencksWorkManager.java (revision 0)
@@ -0,0 +1,36 @@
+package org.jencks;
+
+import java.util.concurrent.Executor;
+import java.util.concurrent.ExecutorService;
+
+import org.apache.geronimo.connector.work.GeronimoWorkManager;
+import org.apache.geronimo.transaction.manager.GeronimoTransactionManager;
+import org.jencks.factory.GeronimoDefaults;
+
+/**
+ * Jencks-specific override of GeronimoWorkManager which takes responsibility for
+ * creating and shutting down its own thread pool.
+ * @author Jerry Shea
+ */
+public class JencksWorkManager extends GeronimoWorkManager {
+
+ private JencksWorkManager(Executor threadPool, GeronimoTransactionManager transactionManager) {
+ super(threadPool, threadPool, threadPool, transactionManager);
+ }
+
+ /**
+ * Public constructor
+ * @param threadPoolSize size of thread pool to create
+ * @param transactionManager
+ */
+ public JencksWorkManager(int threadPoolSize, GeronimoTransactionManager transactionManager) {
+ this(GeronimoDefaults.createThreadPool(threadPoolSize), transactionManager);
+ }
+
+ /**
+ * Override base class implementation to shut down our thread pool
+ */
+ public void doStop() throws Exception {
+ ((ExecutorService)this.getScheduledWorkExecutorPool()).shutdown();
+ }
+}
Index: D:/Development/jencks/src/main/java/org/jencks/factory/GeronimoDefaults.java
===================================================================
--- D:/Development/jencks/src/main/java/org/jencks/factory/GeronimoDefaults.java (revision 176)
+++ D:/Development/jencks/src/main/java/org/jencks/factory/GeronimoDefaults.java (working copy)
@@ -28,12 +28,12 @@
import org.apache.geronimo.connector.outbound.connectionmanagerconfig.PoolingSupport;
import org.apache.geronimo.connector.outbound.connectionmanagerconfig.TransactionSupport;
import org.apache.geronimo.connector.outbound.connectionmanagerconfig.XATransactions;
-import org.apache.geronimo.connector.work.GeronimoWorkManager;
import org.apache.geronimo.transaction.log.UnrecoverableLog;
import org.apache.geronimo.transaction.manager.GeronimoTransactionManager;
import org.apache.geronimo.transaction.manager.TransactionLog;
import org.apache.geronimo.transaction.manager.XidFactory;
import org.apache.geronimo.transaction.manager.XidFactoryImpl;
+import org.jencks.JencksWorkManager;
import org.springframework.beans.FatalBeanException;

/**
@@ -67,10 +67,6 @@
}
}

- public static Executor createThreadPool() {
- return createThreadPool(DEFAULT_THREAD_POOL_SIZE);
- }
-
public static Executor createThreadPool(int threadPoolSize) {
if (threadPoolSize <= 0) threadPoolSize = DEFAULT_THREAD_POOL_SIZE;
Executor pooledExecutor = Executors.newFixedThreadPool(threadPoolSize);
@@ -78,8 +74,7 @@
}

public static WorkManager createWorkManager(GeronimoTransactionManager transactionManager, int threadPoolSize) {
- Executor threadPool = createThreadPool(threadPoolSize);
- WorkManager geronimoWorkManager = new GeronimoWorkManager(threadPool, threadPool, threadPool, transactionManager);
+ WorkManager geronimoWorkManager = new JencksWorkManager(threadPoolSize, transactionManager);
return geronimoWorkManager;
}

Index: D:/Development/jencks/src/main/java/org/jencks/factory/WorkManagerFactoryBean.java
===================================================================
--- D:/Development/jencks/src/main/java/org/jencks/factory/WorkManagerFactoryBean.java (revision 176)
+++ D:/Development/jencks/src/main/java/org/jencks/factory/WorkManagerFactoryBean.java (working copy)
@@ -19,6 +19,7 @@

import org.apache.geronimo.transaction.manager.GeronimoTransactionManager;
import org.apache.geronimo.connector.work.GeronimoWorkManager;
+import org.jencks.JencksWorkManager;
import org.springframework.beans.FatalBeanException;
import org.springframework.beans.factory.FactoryBean;
import org.springframework.beans.factory.InitializingBean;
@@ -42,7 +43,13 @@

public Object getObject() throws Exception {
if (workManager == null) {
- workManager = new GeronimoWorkManager(threadPool, threadPool, threadPool, transactionManager);
+ if (threadPool == null) {
+ // JencksWorkManager will create and destroy the thread pool
+ workManager = new JencksWorkManager(threadPoolSize, transactionManager);
+ }
+ else {
+ workManager = new GeronimoWorkManager(threadPool, threadPool, threadPool, transactionManager);
+ }
workManager.doStart();
}
return workManager;
@@ -68,11 +75,6 @@
if (transactionManager == null) {
throw new FatalBeanException("Geronimo transaction manager was not set");
}
-
- // create a default thread pool if one was not specified
- if (threadPool == null) {
- threadPool = GeronimoDefaults.createThreadPool(getThreadPoolSize());
- }
}

public GeronimoTransactionManager getTransactionManager() {
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Jencks Message driven POJOS threads left running after ctx.destroy

2008-03-01T02:40:15Z

JIRA does not appear to be up - code attached. I didn't touch although I guess this should use a JencksWorkManager if it creates a thread pool.

Cheers, Jerry

On Thu, Feb 28, 2008 at 7:05 PM, Guillaume Nodet <gnodet@...> wrote:

The project is not dead per se. This is just that the project has
fullfilled its purpose
and is no longer actively developped.
If there is a need for another release, I'll do it.
So please, raise a JIRA and attach a patch, i'll review and apply it.

On Thu, Feb 28, 2008 at 8:31 AM, Andrei Ivanov <andrei.ivanov@...> wrote:
> I think it would be nice if you could open an issue for jencks and
> attach the code there...
> Maybe it will even be included in a next version...
> Hmm... http://jira.goopen.org/jira/browse/JCA seems to be dead...
> Well... kind of like this project...
> Post it here then...
> Thank you.
>
>
>
> On 2/28/08, Jerry Shea <jerry.shea@...> wrote:
> > I have solved my problem by inhertiting from the Geronimo work manager and
> > doing exactly that. Do you want the code?
> >
> >
> >
> > On Thu, Feb 28, 2008 at 12:59 AM, Guillaume Nodet <gnodet@...> wrote:
> >
> > > Well, the code seems ok to me, as the thread pools are given to the
> > > work manager.
> > > So they need to be created and shut down from the one that creates the
> > > work manager.
> > > In the jencks case, i'm not sure who does that (haven't looked yet),
> > > but it should be easy
> > > to fix, maybe by inheriting the geronimo work manager and overriding
> > > doStop if needed.
> > >
> > >
> > >
> > >
> > > On Wed, Feb 27, 2008 at 1:58 PM, Andrei Ivanov <andrei.ivanov@...>
> > wrote:
> > > >
> > http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?view=log
> > > >
> > > > It seems that code was removed in rev 392847:
> > > > Make thread pools manageable and make our WorkManager use our thread
> > pools
> > > > under the covers.
> > > >
> > http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?r1=381272&r2=392847
> > > >
> > > >
> > > >
> > > > On 2/27/08, Jerry Shea <jerry.shea@...> wrote:
> > > > > geronimo-connector-2.1 has the same problem (empty doStop method)
> > > > > unfortunately...
> > > > >
> > > > > I'm having difficulty finding any more info on geronimo-connector.
> > It's even
> > > > > proving difficult to find its subversion repository or maybe its just
> > too
> > > > > late at night ;)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Feb 27, 2008 at 9:03 PM, Guillaume Nodet <gnodet@...>
> > wrote:
> > > > >
> > > > > > Yeah, good idea. Maybe a simple version bump would work ?
> > > > > > Have you tried that, or is there any api changes that we need to
> > deal with
> > > > > ?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Feb 27, 2008 at 11:02 AM, Jerry Shea <jerry.shea@...>
> > wrote:
> > > > > > > It looks like a more recent version of GeronimoWorkMnaager shuts
> > down
> > > > > its
> > > > > > > thread pools in the doStop method - see here:
> > > > > > >
> > > > >
> > http://www.docjar.com/html/api/org/apache/geronimo/connector/work/GeronimoWorkManager.java.html
> > > > > > >
> > > > > > > Are there any plans to upgrade the the version of
> > geronimo-connector
> > > > > that
> > > > > > > Jencks 2.1 depends on? I'm more than happy to assist if needed...
> > > > > > >
> > > > > > > Cheers, Jerry
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Feb 27, 2008 at 8:55 PM, JerryShea <jerry.shea@...>
> > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I've cut and pasted the jencks JCA config from
> > > > > > > > http://jencks.org/Message+Driven+POJOs and if
> > I use
> > > > > it like this:
> > > > > > > > AbstractApplicationContext ctx = new
> > > > > > > ClassPathXmlApplicationContext(new
> > > > > > > > String[] {
> > > > > > > > "/spring-jencks.xml",
> > > > > > > > });
> > > > > > > > Thread.sleep(3000);
> > > > > > > > ctx.destroy();
> > > > > > > >
> > > > > > > > after the spring application context has been created, a number
> > of
> > > > > threads
> > > > > > > > are started up (JCAContainer.afterPropertiesSet creates a
> > Geronimo
> > > > > work
> > > > > > > > manager which in turn creates a thread pool).
> > > > > > > >
> > > > > > > > When ctx.destroy is called, JCAContainer.destroy gets called
> > which in
> > > > > turn
> > > > > > > > calls geronimoWorkManager.doStop() which does... nothing!
> > > > > > > >
> > > > > > > > Shouldn't something be shutting down the thread pool? The
> > threads that
> > > > > are
> > > > > > > > created remain alive and prevent my application from closing
> > down.
> > > > > > > >
> > > > > > > > Thx, Jerry
> > > > > > > >
> > > > > > > > --
> > > > > > > > View this message in context:
> > > > > > >
> > > > >
> > http://www.nabble.com/Jencks-Message-driven-POJOS-threads-left-running-after-ctx.destroy-tp15709825p15709825.html
> > > > > > > > Sent from the jencks - user mailing list archive at Nabble.com.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe from this list, please visit:
> > > > > > > >
> > > > > > > > http://xircles.codehaus.org/manage_email
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > > ------------------------
> > > > > > Blog: http://gnodet.blogspot.com/
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe from this list, please visit:
> > > > > >
> > > > > > http://xircles.codehaus.org/manage_email
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe from this list, please visit:
> > > >
> > > > http://xircles.codehaus.org/manage_email
> > > >

> > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > >
> > >
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--

Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Index: D:/Development/jencks/src/main/java/org/jencks/JencksWorkManager.java
===================================================================
--- D:/Development/jencks/src/main/java/org/jencks/JencksWorkManager.java (revision 0)
+++ D:/Development/jencks/src/main/java/org/jencks/JencksWorkManager.java (revision 0)
@@ -0,0 +1,39 @@
+package org.jencks;
+
+import java.util.concurrent.ExecutorService;
+
+import org.apache.geronimo.connector.work.GeronimoWorkManager;
+import org.apache.geronimo.transaction.manager.GeronimoTransactionManager;
+import org.jencks.factory.GeronimoDefaults;
+
+/**
+ * Jencks-specific override of GeronimoWorkManager which creates and shuts down its own
+ * thread pool. This ensures that no threads will be left running after an orderly
+ * shutdown of an instance of this class.
+ * @author Jerry Shea
+ */
+public class JencksWorkManager extends GeronimoWorkManager {
+
+ private ExecutorService threadPool;
+
+ private JencksWorkManager(ExecutorService threadPool, GeronimoTransactionManager transactionManager) {
+ super(threadPool, threadPool, threadPool, transactionManager);
+ this.threadPool = threadPool;
+ }
+
+ /**
+ * Public constructor
+ * @param threadPoolSize size of thread pool to create
+ * @param transactionManager
+ */
+ public JencksWorkManager(int threadPoolSize, GeronimoTransactionManager transactionManager) {
+ this((ExecutorService) GeronimoDefaults.createThreadPool(threadPoolSize), transactionManager);
+ }
+
+ /**
+ * Override base class implementation to shut down our thread pool
+ */
+ public void doStop() throws Exception {
+ threadPool.shutdown();
+ }
+}
Index: D:/Development/jencks/src/main/java/org/jencks/factory/GeronimoDefaults.java
===================================================================
--- D:/Development/jencks/src/main/java/org/jencks/factory/GeronimoDefaults.java (revision 176)
+++ D:/Development/jencks/src/main/java/org/jencks/factory/GeronimoDefaults.java (working copy)
@@ -28,12 +28,12 @@
import org.apache.geronimo.connector.outbound.connectionmanagerconfig.PoolingSupport;
import org.apache.geronimo.connector.outbound.connectionmanagerconfig.TransactionSupport;
import org.apache.geronimo.connector.outbound.connectionmanagerconfig.XATransactions;
-import org.apache.geronimo.connector.work.GeronimoWorkManager;
import org.apache.geronimo.transaction.log.UnrecoverableLog;
import org.apache.geronimo.transaction.manager.GeronimoTransactionManager;
import org.apache.geronimo.transaction.manager.TransactionLog;
import org.apache.geronimo.transaction.manager.XidFactory;
import org.apache.geronimo.transaction.manager.XidFactoryImpl;
+import org.jencks.JencksWorkManager;
import org.springframework.beans.FatalBeanException;

/**
@@ -78,8 +78,7 @@
}

public static WorkManager createWorkManager(GeronimoTransactionManager transactionManager, int threadPoolSize) {
- Executor threadPool = createThreadPool(threadPoolSize);
- WorkManager geronimoWorkManager = new GeronimoWorkManager(threadPool, threadPool, threadPool, transactionManager);
+ WorkManager geronimoWorkManager = new JencksWorkManager(threadPoolSize, transactionManager);
return geronimoWorkManager;
}

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: AMQPool JavaDoc?

2008-02-29T09:10:52Z

You can download the jar and use it locally or on your own web server. That's what I do:

http://repository.codehaus.org/org/jencks/jencks-amqpool/2.1/jencks-amqpool-2.1-javadoc.jar

Any caveats or problems when using Jencks without Spring context?

2008-02-28T22:18:14Z

Are there any potential caveats or problems if Jencks is used programmatically as opposed to with a Spring application context for pooled inbound JMS? For an example of what I am doing please see the code below.

Thanks,

-James

//
TransactionManagerFactoryBean transactionManager = new TransactionManagerFactoryBean();
transactionManager.afterPropertiesSet();
//
WorkManagerFactoryBean workManager = new WorkManagerFactoryBean();
workManager.setTransactionManager((GeronimoTransactionManager) transactionManager.getObject());
workManager.afterPropertiesSet();
//
BootstrapContextFactoryBean bootstrapContext = new BootstrapContextFactoryBean();
bootstrapContext.setTransactionManager((GeronimoTransactionManager)workManager.getObject());
bootstrapContext.setWorkManager((WorkManager)workManager.getObject());
bootstrapContext.afterPropertiesSet();
//
ActiveMQConnectionFactory activeMQConnectionFactory = new ActiveMQConnectionFactory();
activeMQConnectionFactory.setBrokerURL("failover:tcp://127.0.0.1:61616");
activeMQConnectionFactory.setDispatchAsync(false);
activeMQConnectionFactory.setOptimizeAcknowledge(true);
activeMQConnectionFactory.setOptimizedMessageDispatch(true);
//
ActiveMQResourceAdapter resourceAdapter = new ActiveMQResourceAdapter();
resourceAdapter.setConnectionFactory(activeMQConnectionFactory);
resourceAdapter.start((BootstrapContext) bootstrapContext.getObject());
//
JCAContainer jcaContainer = new JCAContainer();
jcaContainer.setBootstrapContext((BootstrapContext)bootstrapContext.getObject());
jcaContainer.setWorkManager((WorkManager)workManager.getObject());
jcaContainer.setTransactionManager((GeronimoTransactionManager)transactionManager.getObject());
jcaContainer.setResourceAdapter(resourceAdapter);
jcaContainer.setLazyLoad(true);
jcaContainer.afterPropertiesSet();
//
ActiveMQActivationSpec activationSpec = new ActiveMQActivationSpec();
activationSpec.setMaxSessions("1");
activationSpec.setMaxMessagesPerSessions("1");
activationSpec.setDestination("Queue.Test.In");
activationSpec.setDestinationType("javax.jms.Queue");
activationSpec.setAcknowledgeMode(ActiveMQActivationSpec.AUTO_ACKNOWLEDGE_MODE);
activationSpec.setResourceAdapter(resourceAdapter);
//
JCAConnectorLifecycleFactory connectorLifecycle = new JCAConnectorLifecycleFactory();
connectorLifecycle.setActivationSpec(activationSpec);
connectorLifecycle.setBootstrapContext((BootstrapContext)bootstrapContext.getObject());
connectorLifecycle.setJcaContainer(jcaContainer);
connectorLifecycle.setResourceAdapter(resourceAdapter);
connectorLifecycle.setTransactionManager((TransactionManager)transactionManager.getObject());
connectorLifecycle.setEndpointFactory(new SingletonEndpointFactory(new MyMessageListener()));
//
JCAConnector connector = connectorLifecycle.startConsumption();
//
// ... RUN APP FOR A WHILE
//
connectorLifecycle.stopConsumption(connector);

Re: Re: jms rollback

2008-02-28T05:20:34Z

Can you maybe produce a small junit test so that the problem can be reproduced
and debugged ?

On Thu, Feb 28, 2008 at 1:34 PM, Andrei Ivanov <andrei.ivanov@...> wrote:

> Hmm... I don't know exactly who should rollback the transaction...
> Using the default behaviour, if an exception happens when the consumer
> processes one message, the next messages aren't seen by the
> consumer...
> I'm not very familiar with JMS and how it is supposed to work, so, my
> sollution was to extend org.jencks.XAEndpoint and do something like:
>
> public void onMessage(Message message) {
> try {
> super.onMessage(message);
> } catch (Exception e) {
> try {
> doRollback(e);
> }
> catch (ResourceException re) {
> throw new RuntimeException(re);
> }
> }
> }
>
> It seems to work... although some more exceptions are beeing logged...
> that's why I was hoping that someone more knowledgeable would look at
> the issue...
>
>
>
> On 2/28/08, Guillaume Nodet <gnodet@...> wrote:
> > I tend to agree with one of the comments posted. I would send it to
> > the ActiveMQ list.
> > Anyway, before reaching the code you mentionned where the exception
> > was discarded,
> > I'd expect someone to commit or rollback the transaction at some
> > point. Isn't it the
> > case ?
> >
> >
> > On Thu, Feb 28, 2008 at 10:30 AM, Andrei Ivanov <andrei.ivanov@...> wrote:
> > > On 11/26/07, Andrei Ivanov <andrei.ivanov@...> wrote:
> > > > Hello,
> > > > I'm having the same problem described at
> > > > http://www.nabble.com/Problems-with-Rollbacks-tf3404998.html
> > > >
> > > > Does anybody know a sollution please?
> > > >
> > >
> > > Since there's been some activity here, I'm asking this again, hoping
> > > for an answer...
> > >
> > >
> > >
> >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

Re: Re: jms rollback

2008-02-28T04:34:48Z

Hmm... I don't know exactly who should rollback the transaction...
Using the default behaviour, if an exception happens when the consumer
processes one message, the next messages aren't seen by the
consumer...
I'm not very familiar with JMS and how it is supposed to work, so, my
sollution was to extend org.jencks.XAEndpoint and do something like:

public void onMessage(Message message) {
try {
super.onMessage(message);
} catch (Exception e) {
try {
doRollback(e);
}
catch (ResourceException re) {
throw new RuntimeException(re);
}
}
}

It seems to work... although some more exceptions are beeing logged...
that's why I was hoping that someone more knowledgeable would look at
the issue...

On 2/28/08, Guillaume Nodet <gnodet@...> wrote:

> I tend to agree with one of the comments posted. I would send it to
> the ActiveMQ list.
> Anyway, before reaching the code you mentionned where the exception
> was discarded,
> I'd expect someone to commit or rollback the transaction at some
> point. Isn't it the
> case ?
>
>
> On Thu, Feb 28, 2008 at 10:30 AM, Andrei Ivanov <andrei.ivanov@...> wrote:
> > On 11/26/07, Andrei Ivanov <andrei.ivanov@...> wrote:
> > > Hello,
> > > I'm having the same problem described at
> > > http://www.nabble.com/Problems-with-Rollbacks-tf3404998.html
> > >
> > > Does anybody know a sollution please?
> > >
> >
> > Since there's been some activity here, I'm asking this again, hoping
> > for an answer...
> >
> >
> >
>
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Re: jms rollback

2008-02-28T01:44:21Z

I tend to agree with one of the comments posted. I would send it to
the ActiveMQ list.
Anyway, before reaching the code you mentionned where the exception
was discarded,
I'd expect someone to commit or rollback the transaction at some
point. Isn't it the
case ?

On Thu, Feb 28, 2008 at 10:30 AM, Andrei Ivanov <andrei.ivanov@...> wrote:

> On 11/26/07, Andrei Ivanov <andrei.ivanov@...> wrote:
> > Hello,
> > I'm having the same problem described at
> > http://www.nabble.com/Problems-with-Rollbacks-tf3404998.html
> >
> > Does anybody know a sollution please?
> >
>
> Since there's been some activity here, I'm asking this again, hoping
> for an answer...
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

Re: jms rollback

2008-02-28T01:30:01Z

On 11/26/07, Andrei Ivanov <andrei.ivanov@...> wrote:
> Hello,
> I'm having the same problem described at
> http://www.nabble.com/Problems-with-Rollbacks-tf3404998.html
>
> Does anybody know a sollution please?
>

Since there's been some activity here, I'm asking this again, hoping
for an answer...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Jencks Message driven POJOS threads left running after ctx.destroy

2008-02-28T00:05:26Z

The project is not dead per se. This is just that the project has
fullfilled its purpose
and is no longer actively developped.
If there is a need for another release, I'll do it.
So please, raise a JIRA and attach a patch, i'll review and apply it.

On Thu, Feb 28, 2008 at 8:31 AM, Andrei Ivanov <andrei.ivanov@...> wrote:

> I think it would be nice if you could open an issue for jencks and
> attach the code there...
> Maybe it will even be included in a next version...
> Hmm... http://jira.goopen.org/jira/browse/JCA seems to be dead...
> Well... kind of like this project...
> Post it here then...
> Thank you.
>
>
>
> On 2/28/08, Jerry Shea <jerry.shea@...> wrote:
> > I have solved my problem by inhertiting from the Geronimo work manager and
> > doing exactly that. Do you want the code?
> >
> >
> >
> > On Thu, Feb 28, 2008 at 12:59 AM, Guillaume Nodet <gnodet@...> wrote:
> >
> > > Well, the code seems ok to me, as the thread pools are given to the
> > > work manager.
> > > So they need to be created and shut down from the one that creates the
> > > work manager.
> > > In the jencks case, i'm not sure who does that (haven't looked yet),
> > > but it should be easy
> > > to fix, maybe by inheriting the geronimo work manager and overriding
> > > doStop if needed.
> > >
> > >
> > >
> > >
> > > On Wed, Feb 27, 2008 at 1:58 PM, Andrei Ivanov <andrei.ivanov@...>
> > wrote:
> > > >
> > http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?view=log
> > > >
> > > > It seems that code was removed in rev 392847:
> > > > Make thread pools manageable and make our WorkManager use our thread
> > pools
> > > > under the covers.
> > > >
> > http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?r1=381272&r2=392847
> > > >
> > > >
> > > >
> > > > On 2/27/08, Jerry Shea <jerry.shea@...> wrote:
> > > > > geronimo-connector-2.1 has the same problem (empty doStop method)
> > > > > unfortunately...
> > > > >
> > > > > I'm having difficulty finding any more info on geronimo-connector.
> > It's even
> > > > > proving difficult to find its subversion repository or maybe its just
> > too
> > > > > late at night ;)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Feb 27, 2008 at 9:03 PM, Guillaume Nodet <gnodet@...>
> > wrote:
> > > > >
> > > > > > Yeah, good idea. Maybe a simple version bump would work ?
> > > > > > Have you tried that, or is there any api changes that we need to
> > deal with
> > > > > ?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Feb 27, 2008 at 11:02 AM, Jerry Shea <jerry.shea@...>
> > wrote:
> > > > > > > It looks like a more recent version of GeronimoWorkMnaager shuts
> > down
> > > > > its
> > > > > > > thread pools in the doStop method - see here:
> > > > > > >
> > > > >
> > http://www.docjar.com/html/api/org/apache/geronimo/connector/work/GeronimoWorkManager.java.html
> > > > > > >
> > > > > > > Are there any plans to upgrade the the version of
> > geronimo-connector
> > > > > that
> > > > > > > Jencks 2.1 depends on? I'm more than happy to assist if needed...
> > > > > > >
> > > > > > > Cheers, Jerry
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Feb 27, 2008 at 8:55 PM, JerryShea <jerry.shea@...>
> > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I've cut and pasted the jencks JCA config from
> > > > > > > > http://jencks.org/Message+Driven+POJOs and if
> > I use
> > > > > it like this:
> > > > > > > > AbstractApplicationContext ctx = new
> > > > > > > ClassPathXmlApplicationContext(new
> > > > > > > > String[] {
> > > > > > > > "/spring-jencks.xml",
> > > > > > > > });
> > > > > > > > Thread.sleep(3000);
> > > > > > > > ctx.destroy();
> > > > > > > >
> > > > > > > > after the spring application context has been created, a number
> > of
> > > > > threads
> > > > > > > > are started up (JCAContainer.afterPropertiesSet creates a
> > Geronimo
> > > > > work
> > > > > > > > manager which in turn creates a thread pool).
> > > > > > > >
> > > > > > > > When ctx.destroy is called, JCAContainer.destroy gets called
> > which in
> > > > > turn
> > > > > > > > calls geronimoWorkManager.doStop() which does... nothing!
> > > > > > > >
> > > > > > > > Shouldn't something be shutting down the thread pool? The
> > threads that
> > > > > are
> > > > > > > > created remain alive and prevent my application from closing
> > down.
> > > > > > > >
> > > > > > > > Thx, Jerry
> > > > > > > >
> > > > > > > > --
> > > > > > > > View this message in context:
> > > > > > >
> > > > >
> > http://www.nabble.com/Jencks-Message-driven-POJOS-threads-left-running-after-ctx.destroy-tp15709825p15709825.html
> > > > > > > > Sent from the jencks - user mailing list archive at Nabble.com.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe from this list, please visit:
> > > > > > > >
> > > > > > > > http://xircles.codehaus.org/manage_email
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > > ------------------------
> > > > > > Blog: http://gnodet.blogspot.com/
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe from this list, please visit:
> > > > > >
> > > > > > http://xircles.codehaus.org/manage_email
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe from this list, please visit:
> > > >
> > > > http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > >
> > >
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

Re: Jencks Message driven POJOS threads left running after ctx.destroy

2008-02-27T23:31:09Z

I think it would be nice if you could open an issue for jencks and
attach the code there...
Maybe it will even be included in a next version...
Hmm... http://jira.goopen.org/jira/browse/JCA seems to be dead...
Well... kind of like this project...
Post it here then...
Thank you.

On 2/28/08, Jerry Shea <jerry.shea@...> wrote:

> I have solved my problem by inhertiting from the Geronimo work manager and
> doing exactly that. Do you want the code?
>
>
>
> On Thu, Feb 28, 2008 at 12:59 AM, Guillaume Nodet <gnodet@...> wrote:
>
> > Well, the code seems ok to me, as the thread pools are given to the
> > work manager.
> > So they need to be created and shut down from the one that creates the
> > work manager.
> > In the jencks case, i'm not sure who does that (haven't looked yet),
> > but it should be easy
> > to fix, maybe by inheriting the geronimo work manager and overriding
> > doStop if needed.
> >
> >
> >
> >
> > On Wed, Feb 27, 2008 at 1:58 PM, Andrei Ivanov <andrei.ivanov@...>
> wrote:
> > >
> http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?view=log
> > >
> > > It seems that code was removed in rev 392847:
> > > Make thread pools manageable and make our WorkManager use our thread
> pools
> > > under the covers.
> > >
> http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?r1=381272&r2=392847
> > >
> > >
> > >
> > > On 2/27/08, Jerry Shea <jerry.shea@...> wrote:
> > > > geronimo-connector-2.1 has the same problem (empty doStop method)
> > > > unfortunately...
> > > >
> > > > I'm having difficulty finding any more info on geronimo-connector.
> It's even
> > > > proving difficult to find its subversion repository or maybe its just
> too
> > > > late at night ;)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Feb 27, 2008 at 9:03 PM, Guillaume Nodet <gnodet@...>
> wrote:
> > > >
> > > > > Yeah, good idea. Maybe a simple version bump would work ?
> > > > > Have you tried that, or is there any api changes that we need to
> deal with
> > > > ?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Feb 27, 2008 at 11:02 AM, Jerry Shea <jerry.shea@...>
> wrote:
> > > > > > It looks like a more recent version of GeronimoWorkMnaager shuts
> down
> > > > its
> > > > > > thread pools in the doStop method - see here:
> > > > > >
> > > >
> http://www.docjar.com/html/api/org/apache/geronimo/connector/work/GeronimoWorkManager.java.html
> > > > > >
> > > > > > Are there any plans to upgrade the the version of
> geronimo-connector
> > > > that
> > > > > > Jencks 2.1 depends on? I'm more than happy to assist if needed...
> > > > > >
> > > > > > Cheers, Jerry
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Feb 27, 2008 at 8:55 PM, JerryShea <jerry.shea@...>
> wrote:
> > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I've cut and pasted the jencks JCA config from
> > > > > > > http://jencks.org/Message+Driven+POJOs and if
> I use
> > > > it like this:
> > > > > > > AbstractApplicationContext ctx = new
> > > > > > ClassPathXmlApplicationContext(new
> > > > > > > String[] {
> > > > > > > "/spring-jencks.xml",
> > > > > > > });
> > > > > > > Thread.sleep(3000);
> > > > > > > ctx.destroy();
> > > > > > >
> > > > > > > after the spring application context has been created, a number
> of
> > > > threads
> > > > > > > are started up (JCAContainer.afterPropertiesSet creates a
> Geronimo
> > > > work
> > > > > > > manager which in turn creates a thread pool).
> > > > > > >
> > > > > > > When ctx.destroy is called, JCAContainer.destroy gets called
> which in
> > > > turn
> > > > > > > calls geronimoWorkManager.doStop() which does... nothing!
> > > > > > >
> > > > > > > Shouldn't something be shutting down the thread pool? The
> threads that
> > > > are
> > > > > > > created remain alive and prevent my application from closing
> down.
> > > > > > >
> > > > > > > Thx, Jerry
> > > > > > >
> > > > > > > --
> > > > > > > View this message in context:
> > > > > >
> > > >
> http://www.nabble.com/Jencks-Message-driven-POJOS-threads-left-running-after-ctx.destroy-tp15709825p15709825.html
> > > > > > > Sent from the jencks - user mailing list archive at Nabble.com.
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe from this list, please visit:
> > > > > > >
> > > > > > > http://xircles.codehaus.org/manage_email
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > > Guillaume Nodet
> > > > > ------------------------
> > > > > Blog: http://gnodet.blogspot.com/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe from this list, please visit:
> > > > >
> > > > > http://xircles.codehaus.org/manage_email
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
> >
> >
> >
> > --
> >
> >
> >
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Jencks Message driven POJOS threads left running after ctx.destroy

2008-02-27T21:45:01Z

I have solved my problem by inhertiting from the Geronimo work manager and doing exactly that. Do you want the code?

On Thu, Feb 28, 2008 at 12:59 AM, Guillaume Nodet <gnodet@...> wrote:

Well, the code seems ok to me, as the thread pools are given to the
work manager.
So they need to be created and shut down from the one that creates the
work manager.
In the jencks case, i'm not sure who does that (haven't looked yet),
but it should be easy
to fix, maybe by inheriting the geronimo work manager and overriding
doStop if needed.

On Wed, Feb 27, 2008 at 1:58 PM, Andrei Ivanov <andrei.ivanov@...> wrote:
> http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?view=log
>
> It seems that code was removed in rev 392847:
> Make thread pools manageable and make our WorkManager use our thread pools
> under the covers.
> http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?r1=381272&r2=392847
>
>
>
> On 2/27/08, Jerry Shea <jerry.shea@...> wrote:
> > geronimo-connector-2.1 has the same problem (empty doStop method)
> > unfortunately...
> >
> > I'm having difficulty finding any more info on geronimo-connector. It's even
> > proving difficult to find its subversion repository or maybe its just too
> > late at night ;)
> >
> >
> >
> >
> >
> > On Wed, Feb 27, 2008 at 9:03 PM, Guillaume Nodet <gnodet@...> wrote:
> >
> > > Yeah, good idea. Maybe a simple version bump would work ?
> > > Have you tried that, or is there any api changes that we need to deal with
> > ?
> > >
> > >
> > >
> > >
> > > On Wed, Feb 27, 2008 at 11:02 AM, Jerry Shea <jerry.shea@...> wrote:
> > > > It looks like a more recent version of GeronimoWorkMnaager shuts down
> > its
> > > > thread pools in the doStop method - see here:
> > > >
> > http://www.docjar.com/html/api/org/apache/geronimo/connector/work/GeronimoWorkManager.java.html
> > > >
> > > > Are there any plans to upgrade the the version of geronimo-connector
> > that
> > > > Jencks 2.1 depends on? I'm more than happy to assist if needed...
> > > >
> > > > Cheers, Jerry
> > > >
> > > >
> > > >
> > > > On Wed, Feb 27, 2008 at 8:55 PM, JerryShea <jerry.shea@...> wrote:
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I've cut and pasted the jencks JCA config from
> > > > > http://jencks.org/Message+Driven+POJOs and if I use
> > it like this:
> > > > > AbstractApplicationContext ctx = new
> > > > ClassPathXmlApplicationContext(new
> > > > > String[] {
> > > > > "/spring-jencks.xml",
> > > > > });
> > > > > Thread.sleep(3000);
> > > > > ctx.destroy();
> > > > >
> > > > > after the spring application context has been created, a number of
> > threads
> > > > > are started up (JCAContainer.afterPropertiesSet creates a Geronimo
> > work
> > > > > manager which in turn creates a thread pool).
> > > > >
> > > > > When ctx.destroy is called, JCAContainer.destroy gets called which in
> > turn
> > > > > calls geronimoWorkManager.doStop() which does... nothing!
> > > > >
> > > > > Shouldn't something be shutting down the thread pool? The threads that
> > are
> > > > > created remain alive and prevent my application from closing down.
> > > > >
> > > > > Thx, Jerry
> > > > >
> > > > > --
> > > > > View this message in context:
> > > >
> > http://www.nabble.com/Jencks-Message-driven-POJOS-threads-left-running-after-ctx.destroy-tp15709825p15709825.html
> > > > > Sent from the jencks - user mailing list archive at Nabble.com.
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe from this list, please visit:
> > > > >
> > > > > http://xircles.codehaus.org/manage_email
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > >
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--

Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Jencks Message driven POJOS threads left running after ctx.destroy

2008-02-27T05:59:11Z

Well, the code seems ok to me, as the thread pools are given to the
work manager.
So they need to be created and shut down from the one that creates the
work manager.
In the jencks case, i'm not sure who does that (haven't looked yet),
but it should be easy
to fix, maybe by inheriting the geronimo work manager and overriding
doStop if needed.

On Wed, Feb 27, 2008 at 1:58 PM, Andrei Ivanov <andrei.ivanov@...> wrote:

> http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?view=log
>
> It seems that code was removed in rev 392847:
> Make thread pools manageable and make our WorkManager use our thread pools
> under the covers.
> http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?r1=381272&r2=392847
>
>
>
> On 2/27/08, Jerry Shea <jerry.shea@...> wrote:
> > geronimo-connector-2.1 has the same problem (empty doStop method)
> > unfortunately...
> >
> > I'm having difficulty finding any more info on geronimo-connector. It's even
> > proving difficult to find its subversion repository or maybe its just too
> > late at night ;)
> >
> >
> >
> >
> >
> > On Wed, Feb 27, 2008 at 9:03 PM, Guillaume Nodet <gnodet@...> wrote:
> >
> > > Yeah, good idea. Maybe a simple version bump would work ?
> > > Have you tried that, or is there any api changes that we need to deal with
> > ?
> > >
> > >
> > >
> > >
> > > On Wed, Feb 27, 2008 at 11:02 AM, Jerry Shea <jerry.shea@...> wrote:
> > > > It looks like a more recent version of GeronimoWorkMnaager shuts down
> > its
> > > > thread pools in the doStop method - see here:
> > > >
> > http://www.docjar.com/html/api/org/apache/geronimo/connector/work/GeronimoWorkManager.java.html
> > > >
> > > > Are there any plans to upgrade the the version of geronimo-connector
> > that
> > > > Jencks 2.1 depends on? I'm more than happy to assist if needed...
> > > >
> > > > Cheers, Jerry
> > > >
> > > >
> > > >
> > > > On Wed, Feb 27, 2008 at 8:55 PM, JerryShea <jerry.shea@...> wrote:
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I've cut and pasted the jencks JCA config from
> > > > > http://jencks.org/Message+Driven+POJOs and if I use
> > it like this:
> > > > > AbstractApplicationContext ctx = new
> > > > ClassPathXmlApplicationContext(new
> > > > > String[] {
> > > > > "/spring-jencks.xml",
> > > > > });
> > > > > Thread.sleep(3000);
> > > > > ctx.destroy();
> > > > >
> > > > > after the spring application context has been created, a number of
> > threads
> > > > > are started up (JCAContainer.afterPropertiesSet creates a Geronimo
> > work
> > > > > manager which in turn creates a thread pool).
> > > > >
> > > > > When ctx.destroy is called, JCAContainer.destroy gets called which in
> > turn
> > > > > calls geronimoWorkManager.doStop() which does... nothing!
> > > > >
> > > > > Shouldn't something be shutting down the thread pool? The threads that
> > are
> > > > > created remain alive and prevent my application from closing down.
> > > > >
> > > > > Thx, Jerry
> > > > >
> > > > > --
> > > > > View this message in context:
> > > >
> > http://www.nabble.com/Jencks-Message-driven-POJOS-threads-left-running-after-ctx.destroy-tp15709825p15709825.html
> > > > > Sent from the jencks - user mailing list archive at Nabble.com.
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe from this list, please visit:
> > > > >
> > > > > http://xircles.codehaus.org/manage_email
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > >
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

Re: Jencks Message driven POJOS threads left running after ctx.destroy

2008-02-27T04:58:53Z

http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?view=log

It seems that code was removed in rev 392847:
Make thread pools manageable and make our WorkManager use our thread pools
under the covers.
http://svn.apache.org/viewvc/geronimo/components/txmanager/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java?r1=381272&r2=392847

On 2/27/08, Jerry Shea <jerry.shea@...> wrote:

> geronimo-connector-2.1 has the same problem (empty doStop method)
> unfortunately...
>
> I'm having difficulty finding any more info on geronimo-connector. It's even
> proving difficult to find its subversion repository or maybe its just too
> late at night ;)
>
>
>
>
>
> On Wed, Feb 27, 2008 at 9:03 PM, Guillaume Nodet <gnodet@...> wrote:
>
> > Yeah, good idea. Maybe a simple version bump would work ?
> > Have you tried that, or is there any api changes that we need to deal with
> ?
> >
> >
> >
> >
> > On Wed, Feb 27, 2008 at 11:02 AM, Jerry Shea <jerry.shea@...> wrote:
> > > It looks like a more recent version of GeronimoWorkMnaager shuts down
> its
> > > thread pools in the doStop method - see here:
> > >
> http://www.docjar.com/html/api/org/apache/geronimo/connector/work/GeronimoWorkManager.java.html
> > >
> > > Are there any plans to upgrade the the version of geronimo-connector
> that
> > > Jencks 2.1 depends on? I'm more than happy to assist if needed...
> > >
> > > Cheers, Jerry
> > >
> > >
> > >
> > > On Wed, Feb 27, 2008 at 8:55 PM, JerryShea <jerry.shea@...> wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > I've cut and pasted the jencks JCA config from
> > > > http://jencks.org/Message+Driven+POJOs and if I use
> it like this:
> > > > AbstractApplicationContext ctx = new
> > > ClassPathXmlApplicationContext(new
> > > > String[] {
> > > > "/spring-jencks.xml",
> > > > });
> > > > Thread.sleep(3000);
> > > > ctx.destroy();
> > > >
> > > > after the spring application context has been created, a number of
> threads
> > > > are started up (JCAContainer.afterPropertiesSet creates a Geronimo
> work
> > > > manager which in turn creates a thread pool).
> > > >
> > > > When ctx.destroy is called, JCAContainer.destroy gets called which in
> turn
> > > > calls geronimoWorkManager.doStop() which does... nothing!
> > > >
> > > > Shouldn't something be shutting down the thread pool? The threads that
> are
> > > > created remain alive and prevent my application from closing down.
> > > >
> > > > Thx, Jerry
> > > >
> > > > --
> > > > View this message in context:
> > >
> http://www.nabble.com/Jencks-Message-driven-POJOS-threads-left-running-after-ctx.destroy-tp15709825p15709825.html
> > > > Sent from the jencks - user mailing list archive at Nabble.com.
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list, please visit:
> > > >
> > > > http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email