Atomikos Forum

I am working on porting a working application into OSGi/Maven style bundles. This works in the original application, but in the new alternate version I get the exception at the bottom of this post.

I have three databases that I am connecting to. 2 are MySQL, and 1 is SqlServer. The two MySQL work fine, the SqlServer one is the problem. The settings are the same, so why am I getting this exception?

[code:title=SqlServer Bean]
    <bean id="abstractSqlServerDatasource"
    class="com.atomikos.jdbc.nonxa.AtomikosNonXADataSourceBean">
        <property name="driverClassName" value="net.sourceforge.jtds.jdbc.Driver" />
        <property name="minPoolSize" value="5" />
        <property name="maxPoolSize" value="50" />
        <property name="borrowConnectionTimeout" value="60" />
        <property name="testQuery" value = "select version()" />
    </bean>
    
    <bean id="sqlserverDataSource" parent="abstractSqlServerDatasource"
    init-method="init" destroy-method="close">
        <property name="uniqueResourceName" value="sqlserver/db" />
        <property name="url"
            value="jdbc:jtds:sqlserver://${db.host}:${db.port}/${db.schema}" />
        <property name="user" value="${db.username}" />
        <property name="password" value="${db.password}" />
    </bean>
[code]

[code:title=Working MySQL Configuration]
    <bean id="abstractMySQLDatasource" class="com.atomikos.jdbc.nonxa.AtomikosNonXADataSourceBean">
        <property name="driverClassName" value="com.mysql.jdbc.Driver" />
        <property name="minPoolSize" value="5" />
        <property name="maxPoolSize" value="50" />
        <property name="borrowConnectionTimeout" value="60" />
        <property name="testQuery" value = "select version()" />
    </bean>
    
    <bean id="mysqlDataSource" parent="abstractMySQLDatasource"
    init-method="init" destroy-method="close">
        <property name="uniqueResourceName" value="mySQL/db" />
        <property name="url"
            value="jdbc:mysql://${mysqldb.host}:${mysqldb.port}/${dbmysql.schema}" />
        <property name="user">
            <value>${mysqldb.user}</value>
        </property>
        <property name="password">
            <value>${mysqldb.passwd}</value>
        </property>
    </bean>
[code]

[code:title=Exception]
[2010-09-17 16:44:30.985] aultQuartzScheduler_Worker-3 org.quartz.core.ErrorLogger                                      Job (DEFAULT.serviceFetcherJobDetailBean threw an exception. org.quartz.SchedulerException: Job threw an unhandled exception.
    at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
    at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:525)
Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is com.atomikos.jdbc.AtomikosSQLException: Connection pool exhausted - try increasing 'maxPoolSize' and/or 'borrowConnectionTimeout' on the DataSourceBean.
    at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:82)
    at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:381)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:455)
    at org.springframework.jdbc.core.JdbcTemplate.queryForRowSet(JdbcTemplate.java:498)
    at mynamespace.service.dao.impl.mssql.DaoImpl.fetchAllTags(DaoImpl.java:46)
    at mynamespace.service.dao.impl.mssql.DaoImpl.fetchTagForDeviceId(DaoImpl.java:28)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:616)
    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
    at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:58)
    at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:62)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
    at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.osgi.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:59)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
    at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
    at $Proxy236.fetchTagForDeviceId(Unknown Source)
    at mynamespace.service.jobs.fetcher.Fetcher.fetch(Fetcher.java:103)
    at mynamespace.service.jobs.ServiceFetcherJob.fetch(ServiceFetcherJob.java:36)
    at mynamespace.service.jobs.ServiceFetcherJob.executeInternal(ServiceFetcherJob.java:26)
    at org.springframework.scheduling.quartz.QuartzJobBean.execute(QuartzJobBean.java:86)
    at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
    ... 1 common frames omitted
Caused by: com.atomikos.jdbc.AtomikosSQLException: Connection pool exhausted - try increasing 'maxPoolSize' and/or 'borrowConnectionTimeout' on the DataSourceBean.
    at com.atomikos.jdbc.AtomikosSQLException.throwAtomikosSQLException(AtomikosSQLException.java:19)
    at com.atomikos.jdbc.AbstractDataSourceBean.throwAtomikosSQLException(AbstractDataSourceBean.java:62)
    at com.atomikos.jdbc.AbstractDataSourceBean.throwAtomikosSQLException(AbstractDataSourceBean.java:57)
    at com.atomikos.jdbc.AbstractDataSourceBean.getConnection(AbstractDataSourceBean.java:294)
    at com.atomikos.jdbc.nonxa.AtomikosNonXADataSourceBean.getConnection(AtomikosNonXADataSourceBean.java:180)
    at com.atomikos.jdbc.AbstractDataSourceBean.getConnection(AbstractDataSourceBean.java:341)
    at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113)
    at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79)
    ... 29 common frames omitted
[code]

Hard to say without the tm.out logs...

I am using Eclipse Virgo (formerly Spring-DM Server), I do not see a tm.out file. What kind of information are you looking for? I don't actually know what tm.out is.

It's our dedicated log file (like log4j if you like) and contains all interactions that matter for the JTA/XA part.

I do not see such a file on my system, and tm.out was not found. I am using default properties, jta.properties does not exist if that makes a difference.

I am obviously new with Atomikos, is there a default location that this would normally live? Or could it be called something different?

Default is the working dir of your application or JVM.

If your datasource gets used by more client apps then you should increase the poolSize, BTW. Maybe that is the explanation.

Guy

Right now my application looks something like this:

A) Quartz Bundle, allows jobs to be hot deployed or removed from the scheduler

B) SqlServer Bundle, Atomikos instance

C) Job Bundle

C depends on both A and B via OSGi

No other modules are using SqlServer at this time (although certainly more will be added eventually)

So I would be surprised if the pool is actually getting too large as only the one client is accessing SqlServer and it is only making one call and then caching the results.

I also tried increasing the max pool size, but that didn't help. I took the max from 50 to 100.

As far as the working directory. I am not sure if that is going to be the Virgo working directory, or somehow specific to A, B, or C. Either way, I still cannot find tm.out on my server. Is there a way that I can force the log to generate at a location of my choosing?

I added jta.properties to src/main/resources/jta.properties for each bundle involved.

jta.properties looks like this:
[root@testserver current]# cat /home/user/jta.properties
com.atomikos.icatch.log_base_dir = /opt/virgo/current/serviceability/atomikos
com.atomikos.icatch.output_dir = /opt/virgo/current/serviceability/atomikos
com.atomikos.icatch.tm_unique_name = [bundle_name]
com.atomikos.icatch.console_log_level = DEBUG

Still no logging for atomikos. Is there something else I could try?

OK regarding the logging: does startup of the app print the properties file to System.err? Does it pick up the properties file you want?

I also started a topic over at the Virgo Forum:
http://www.eclipse.org/forums/index.php?t=rview&goto=628804#msg_628804

They are asking what logging mechanism Atomikos uses? It seems that it is possible that Virgo might be redirecting the logs somehow. Knowing what Atomikos is using might help them determine if Virgo is redirecting the logs.

In the meantime, I will work on verifying if the jta.properties file is actually being loaded.

Thanks,
Dennis

JDK logging by default plus log4j if you put slf4j-log4j jars in your classpath...

"./bin/startup.sh > output 2>err", produced no stderr logs.

log4j is available on all my bundles.

I unzipped one of my bundles to confirm jta.properties is physically located in the root of the classpath.

Any other way I might be able to determine if jta.properties is being loaded? At this point I am wondering if it is not.

So Atomikos expects that the jta.properties file will always be in the root of the application's classpath. For a normal Java application, this wouldn't be a problem. But in the case of OSGi, there is a root classpath for the bundle, but does that equate to the root classpath of the application?

I wonder if Atomikos is looking at the Virgo root classpath instead of the bundle's? Is that possible? If so, then I would imagine default logging would be being utilized. So that still wouldn't explain why I am not getting any logs, but may explain why jta.properties is seemingly ignored.

Thoughts?

Hi,

I'm the person who help atomikos into the OSGi fication of their (excellent) product.
I need to say that the version you use is a very first try : next version will be far much better.

Though the current version is usable and here is how I used It :

I create a bundle (https://dynaresume.googlecode.com/svn/tags/BACKUP_BACK_TO_SVN/infrastructure/org.dynaresume.infrastructure.jtatransaction) which holds the JTA configuration (see the module-context.xml) and export an OSGi service the implements Spring's org.springframework.transaction.PlatformTransactionManager as JTA Service. as you can notice, you can easily customize the trace level there.

I create my DB config as decribe in this bundle (https://dynaresume.googlecode.com/svn/tags/BACKUP_BACK_TO_SVN/infrastructure/org.dynaresume.infrastructure.db).

I faced several classloading issues and that why I used "patch" the atomikos bunbles with fragment to allow them to access certain pakages of the JDBC driver (https://dynaresume.googlecode.com/svn/tags/BACKUP_BACK_TO_SVN/infrastructure/com.atomikos.transactions.datasource.xa.fragment and https://dynaresume.googlecode.com/svn/tags/BACKUP_BACK_TO_SVN/infrastructure/com.atomikos.transactions-jdbc.derby.fragment).

Hope this helps.

Thank you! That was exactly what I needed.

To get logging work, I basically just followed org.dynaresume.infrastructure.jtatransaction. I am not certain I fully understood the other modules, but the one was enough to get logging to work. Once I had logging, I quickly identified the trivial bug that was causing me headaches.

Thank you for your help.