You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Vincent Guerin <ta...@gmail.com> on 2007/06/21 11:17:11 UTC
Transaction problem with the JCA connector under Sun Java System
Application Server Platform Edition 9.0_01 (build b02)
Hi,
Our project processes quite a lot of files (zip and XML) their size ranges
from a few bytes to one (or few megabytes). We are storing on a complex tree
structure on jackrabbit.
For that purpose, we are using two stateless EJB, one for internal needs
(business logic) and one as an API to use jackrabbit (that EJB is used to
connect to the JCA connector – by Resource annotation).
We are using the default storage system of Jackrabbit
(org.apache.jackrabbit.core.fs.local.LocalFileSystem).
This project is working fine on a limited number of files but generates a
memory overflow (java.lang.OutOfMemoryError: Java heap space) whenever we
are switching to real mode with a huge amount of files.
After a few tests, we are guessing that the problem comes from the fact that
the transactions commit (actual recording of the data in the repository) is
only done at the end of the process (at the end of the EJB business logic
process).
Is it possible to make commit of a relative form throughout our process and
if yes, how ?
In other words, can I force the writing on the disk as fast as possible
(directly into the repository in fact) ?
Under SJSAS if I set the « Transaction Support » of my Connector Connection
Pools to « No Transaction », would it solve my problem ?
Vincent Guerin.
The exception :
javax.ejb.TransactionRolledbackLocalException: Exception thrown from bean;
nested exception is: javax.ejb.EJBException
javax.ejb.EJBException
at
com.sun.ejb.containers.InvocationHandlerUtil.throwLocalException(InvocationHandlerUtil.java:99)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:195)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:118)
at $Proxy49.processIncomingFiles(Unknown Source)
at
com.dalloz.download.ejb.ProcessDownloadBean.downloadFilesFromFTP(ProcessDownloadBean.java:61)
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
com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2766)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3847)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:184)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:118)
at $Proxy48.downloadFilesFromFTP(Unknown Source)
at
com.dalloz.download.ejb.ProcessDownloadMDB.onMessage(ProcessDownloadMDB.java:68)
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
com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
at
com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:3866)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:414)
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:188)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3839)
at
com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:997)
at
com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:61)
--
View this message in context: http://www.nabble.com/Transaction-problem-with-the-JCA-connector-under-Sun-Java-System-Application-Server-Platform-Edition-9.0_01-%28build-b02%29-tf3957491.html#a11229447
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Transaction problem with the JCA connector under Sun Java
System Application Server Platform Edition 9.0_01 (build b02)
Posted by Vincent Guerin <ta...@gmail.com>.
Thank you very much for your answer Dominique. It confirms our intuition.
I think that we will use the two modes, without transaction for
initialization (massive upload) and with transaction for the usual upload.
Kind regards,
Vincent.
Dominique Pfister wrote:
>
> Hi Vincent,
>
> I'm not familiar with SJSAS, but as you correctly pointed out, every
> modification is written to a memory-based "change log", until the
> overall change is committed. This may result in an OutOfMemoryError if
> the changes exceed the available memory. Setting your connector
> transaction level to "NoTransaction" might actually remedy this issue,
> but keep in mind, that some file uploads may then fail while other
> succeed, leaving you in the situation of manually cleaning up whatever
> might have gone wrong. I'd recommend to keep the transaction level and
> upload smaller amounts of files, which is still not optimal but
> probably easier to handle in case of an error.
>
> Kind regards
> Dominique
>
> On 6/21/07, Vincent Guerin <ta...@gmail.com> wrote:
>>
>> Hi,
>>
>> Our project processes quite a lot of files (zip and XML) their size
>> ranges
>> from a few bytes to one (or few megabytes). We are storing on a complex
>> tree
>> structure on jackrabbit.
>>
>> For that purpose, we are using two stateless EJB, one for internal needs
>> (business logic) and one as an API to use jackrabbit (that EJB is used to
>> connect to the JCA connector – by Resource annotation).
>> We are using the default storage system of Jackrabbit
>> (org.apache.jackrabbit.core.fs.local.LocalFileSystem).
>>
>> This project is working fine on a limited number of files but generates a
>> memory overflow (java.lang.OutOfMemoryError: Java heap space) whenever we
>> are switching to real mode with a huge amount of files.
>>
>> After a few tests, we are guessing that the problem comes from the fact
>> that
>> the transactions commit (actual recording of the data in the repository)
>> is
>> only done at the end of the process (at the end of the EJB business logic
>> process).
>>
>> Is it possible to make commit of a relative form throughout our process
>> and
>> if yes, how ?
>> In other words, can I force the writing on the disk as fast as possible
>> (directly into the repository in fact) ?
>>
>> Under SJSAS if I set the « Transaction Support » of my Connector
>> Connection
>> Pools to « No Transaction », would it solve my problem ?
>>
>> Vincent Guerin.
>>
>>
>> The exception :
>>
>> javax.ejb.TransactionRolledbackLocalException: Exception thrown from
>> bean;
>> nested exception is: javax.ejb.EJBException
>> javax.ejb.EJBException
>> at
>> com.sun.ejb.containers.InvocationHandlerUtil.throwLocalException(InvocationHandlerUtil.java:99)
>> at
>> com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:195)
>> at
>> com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:118)
>> at $Proxy49.processIncomingFiles(Unknown Source)
>> at
>> com.dalloz.download.ejb.ProcessDownloadBean.downloadFilesFromFTP(ProcessDownloadBean.java:61)
>> 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
>> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050)
>> at
>> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
>> at
>> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2766)
>> at
>> com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3847)
>> at
>> com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:184)
>> at
>> com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:118)
>> at $Proxy48.downloadFilesFromFTP(Unknown Source)
>> at
>> com.dalloz.download.ejb.ProcessDownloadMDB.onMessage(ProcessDownloadMDB.java:68)
>> 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
>> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050)
>> at
>> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
>> at
>> com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:3866)
>> at
>> com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:414)
>> at
>> com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:188)
>> at
>> com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3839)
>> at
>> com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:997)
>> at
>> com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:61)
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Transaction-problem-with-the-JCA-connector-under-Sun-Java-System-Application-Server-Platform-Edition-9.0_01-%28build-b02%29-tf3957491.html#a11229447
>> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Transaction-problem-with-the-JCA-connector-under-Sun-Java-System-Application-Server-Platform-Edition-9.0_01-%28build-b02%29-tf3957491.html#a11232232
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Transaction problem with the JCA connector under Sun Java System Application Server Platform Edition 9.0_01 (build b02)
Posted by Dominique Pfister <do...@day.com>.
Hi Vincent,
I'm not familiar with SJSAS, but as you correctly pointed out, every
modification is written to a memory-based "change log", until the
overall change is committed. This may result in an OutOfMemoryError if
the changes exceed the available memory. Setting your connector
transaction level to "NoTransaction" might actually remedy this issue,
but keep in mind, that some file uploads may then fail while other
succeed, leaving you in the situation of manually cleaning up whatever
might have gone wrong. I'd recommend to keep the transaction level and
upload smaller amounts of files, which is still not optimal but
probably easier to handle in case of an error.
Kind regards
Dominique
On 6/21/07, Vincent Guerin <ta...@gmail.com> wrote:
>
> Hi,
>
> Our project processes quite a lot of files (zip and XML) their size ranges
> from a few bytes to one (or few megabytes). We are storing on a complex tree
> structure on jackrabbit.
>
> For that purpose, we are using two stateless EJB, one for internal needs
> (business logic) and one as an API to use jackrabbit (that EJB is used to
> connect to the JCA connector – by Resource annotation).
> We are using the default storage system of Jackrabbit
> (org.apache.jackrabbit.core.fs.local.LocalFileSystem).
>
> This project is working fine on a limited number of files but generates a
> memory overflow (java.lang.OutOfMemoryError: Java heap space) whenever we
> are switching to real mode with a huge amount of files.
>
> After a few tests, we are guessing that the problem comes from the fact that
> the transactions commit (actual recording of the data in the repository) is
> only done at the end of the process (at the end of the EJB business logic
> process).
>
> Is it possible to make commit of a relative form throughout our process and
> if yes, how ?
> In other words, can I force the writing on the disk as fast as possible
> (directly into the repository in fact) ?
>
> Under SJSAS if I set the « Transaction Support » of my Connector Connection
> Pools to « No Transaction », would it solve my problem ?
>
> Vincent Guerin.
>
>
> The exception :
>
> javax.ejb.TransactionRolledbackLocalException: Exception thrown from bean;
> nested exception is: javax.ejb.EJBException
> javax.ejb.EJBException
> at
> com.sun.ejb.containers.InvocationHandlerUtil.throwLocalException(InvocationHandlerUtil.java:99)
> at
> com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:195)
> at
> com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:118)
> at $Proxy49.processIncomingFiles(Unknown Source)
> at
> com.dalloz.download.ejb.ProcessDownloadBean.downloadFilesFromFTP(ProcessDownloadBean.java:61)
> 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
> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050)
> at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
> at
> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2766)
> at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3847)
> at
> com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:184)
> at
> com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:118)
> at $Proxy48.downloadFilesFromFTP(Unknown Source)
> at
> com.dalloz.download.ejb.ProcessDownloadMDB.onMessage(ProcessDownloadMDB.java:68)
> 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
> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050)
> at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
> at
> com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:3866)
> at
> com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:414)
> at
> com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:188)
> at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3839)
> at
> com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:997)
> at
> com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:61)
>
>
> --
> View this message in context: http://www.nabble.com/Transaction-problem-with-the-JCA-connector-under-Sun-Java-System-Application-Server-Platform-Edition-9.0_01-%28build-b02%29-tf3957491.html#a11229447
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>
>