Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » org.eclipse.persistence.exceptions.ValidationException thrown due to NegativeArraySizeException
org.eclipse.persistence.exceptions.ValidationException thrown due to NegativeArraySizeException [message #540635] Wed, 16 June 2010 19:01 Go to next message
Tim is currently offline TimFriend
Messages: 21
Registered: June 2010
Junior Member
We are seeing NegativeArraySizeExceptions happening on a regular basis when running our app using the JPA interface to Eclipselink 2.0.2. Specifically, the stack trace has:
org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is Exception [EclipseLink-7107] (Eclipse Persistence Services - 2.0.2.v20100323-r6872): org.eclipse.persistence.exceptions.ValidationException 
Exception Description: Error encountered during string decryption. 
Internal Exception: java.lang.NegativeArraySizeException 
org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:382) 
org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:371) 
org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:317) 
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:105) 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) 
org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625) 
.
.
.
root cause 
Exception [EclipseLink-7107] (Eclipse Persistence Services - 2.0.2.v20100323-r6872): org.eclipse.persistence.exceptions.ValidationException 
Exception Description: Error encountered during string decryption. 
Internal Exception: java.lang.NegativeArraySizeException 
org.eclipse.persistence.exceptions.ValidationException.errorDecryptingPassword(ValidationException.java:849) 
org.eclipse.persistence.internal.security.JCEEncryptor.decryptPassword(JCEEncryptor.java:102) 
org.eclipse.persistence.sessions.DatasourceLogin.prepareProperties(DatasourceLogin.java:323) 
org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162) 
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:327) 
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:295) 
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:558) 
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1436) 
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:302) 
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.beginTransaction(DatasourceAccessor.java:235) 
org.eclipse.persistence.internal.sessions.AbstractSession.basicBeginTransaction(AbstractSession.java:424) 
org.eclipse.persistence.internal.sessions.AbstractSession.basicBeginTransaction(AbstractSession.java:413) 
org.eclipse.persistence.sessions.server.ClientSession.basicBeginTransaction(ClientSession.java:134) 
org.eclipse.persistence.internal.sessions.AbstractSession.beginTransaction(AbstractSession.java:580) 
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.beginTransaction(UnitOfWorkImpl.java:554) 
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.beginEarlyTransaction(UnitOfWorkImpl.java:544) 
org.springframework.orm.jpa.vendor.EclipseLinkJpaDialect.beginTransaction(EclipseLinkJpaDialect.java:90) 
org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:332) 
org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java


It doesn't happen every time, but happens with reasonable frequency.

I've set up break points in JCEEncryptor and have been able to catch the exception in action. The confusing part (to me at least) is that the calls to the method seem to be the same as previous calls which return a valid value. In our case, the method is being called with "5C4C6924B1B14E16", which is the encrypted form of "". We are using Tomcat with a JNDI datasource, so there is no password in this instance (which makes me wonder why this code is called at all). If I use a JPA defined datasource, I don't see the exceptions happen, though it is hard to say this is definitive, since I'm unable able to explicitly reproduce the error and generally just need to hit the server with requests for a while to trigger it.

I saw something similar in this thread, but there didn't seem to be a solution.

We are using org.springframework.orm.jpa.persistenceunit.PersistenceUnitP ostProcessor to set up the JNDI datasource.

Anyone have any idea what might be happening and how to prevent it? If not, any further debugging information which I can provide to help track down the issue? Like I said, I can trigger it on occasion and have done so in the debugger. I just honestly can't figure out why some calls with the same arg to JCEEncryptor work while others throw an exception.

Thanks.

--Tim
Re: org.eclipse.persistence.exceptions.ValidationException thrown due to NegativeArraySizeException [message #540856 is a reply to message #540635] Thu, 17 June 2010 13:48 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 1039
Registered: July 2009
Senior Member
Hello,

The linked thread shows that the internal error is occuring from
com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA12275)
at javax.crypto.Cipher.doFinal(DashoA12275)
at javax.crypto.CipherInputStream.close(DashoA12275)
at
java.io.ObjectInputStream$PeekInputStream.close(ObjectInputS tream.java:2252)
at
java.io.ObjectInputStream$BlockDataInputStream.close(ObjectI nputStream.java:2587)
at java.io.ObjectInputStream.close(ObjectInputStream.java:853)
JCEEncryptor.decry ptPassword(JCEEncryptor.java:91)

Is your error the same (and can you post it if not)? If so, it is strange that the error occurs after the password is decrypted when resources are now being closed. What JDK are you using, and have you looked at JDK bugs? Can you try the latest JDK if you are not already?

Regards,
Chris
Re: org.eclipse.persistence.exceptions.ValidationException thrown due to NegativeArraySizeException [message #540900 is a reply to message #540856] Thu, 17 June 2010 15:06 Go to previous messageGo to next message
Tim is currently offline TimFriend
Messages: 21
Registered: June 2010
Junior Member
Sorry. Forgot ton include the entire stack. The root-root cause was:
root cause 
java.lang.NegativeArraySizeException 
com.sun.crypto.provider.SunJCE_f.a(DashoA13*..) 
com.sun.crypto.provider.DESCipher.engineUpdate(DashoA13*..) 
javax.crypto.Cipher.update(DashoA13*..) 
javax.crypto.CipherInputStream.a(DashoA13*..) 
javax.crypto.CipherInputStream.read(DashoA13*..) 
java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2266) 
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2279) 
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750) 
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) 
java.io.ObjectInputStream.<init>(ObjectInputStream.java:280) 
org.eclipse.persistence.internal.security.JCEEncryptor.decryptPassword(JCEEncryptor.java:88) 
org.eclipse.persistence.sessions.DatasourceLogin.prepareProperties(DatasourceLogin.java:323) 
org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162) 
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:327) 
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:295) 
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:558) 
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1436) 
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:302) 
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.beginTransaction(DatasourceAccessor.java:235) 
org.eclipse.persistence.internal.sessions.AbstractSession.basicBeginTransaction(AbstractSession.java:424) 
org.eclipse.persistence.internal.sessions.AbstractSession.basicBeginTransaction(AbstractSession.java:413) 
org.eclipse.persistence.sessions.server.ClientSession.basicBeginTransaction(ClientSession.java:134) 
org.eclipse.persistence.internal.sessions.AbstractSession.beginTransaction(AbstractSession.java:580) 
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.beginTransaction(UnitOfWorkImpl.java:554) 
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.beginEarlyTransaction(UnitOfWorkImpl.java:544) 
org.springframework.orm.jpa.vendor.EclipseLinkJpaDialect.beginTransaction(EclipseLinkJpaDialect.java:90) 
org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:332) 
org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:371) 
org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:317) 
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:105) 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) 


This has happened on both RHEL5.xx64 with:
# java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)

and MacOSX with:
% java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)


So it is possible that it is JDK related, but we have two different (and fairly recent) versions. My gut feel is that since we're seeing what one would expect to be a deterministic method displaying different behaviors with the same inputs, that we either have some thread unsafe code or it is possible that some underlying initialization of the security code is not happening cleanly.

--Tim
Re: org.eclipse.persistence.exceptions.ValidationException thrown due to NegativeArraySizeException [message #542060 is a reply to message #540900] Wed, 23 June 2010 16:39 Go to previous messageGo to next message
Tim is currently offline TimFriend
Messages: 21
Registered: June 2010
Junior Member
Still not having any luck with this, though it does appear that this cropped up with Toplink many moons ago. See this post on the Toplink forum. I don't have access to the Oracle bug database (at least as far as I can determine), so I can't follow up with the issues listed there.

I would assume that the fix made it into the Eclipselink code since it is from five years ago, but it really sounds like the same issue. Is it possible there was a regression? That the fix never made it in to Eclipselink for some reason? Can someone at Oracle track down the details from the original issues and see if they might still apply or post details so that I can try and confirm that the issue is the same?

Thanks.

--Tim
Re: org.eclipse.persistence.exceptions.ValidationException thrown due to NegativeArraySizeException [message #542462 is a reply to message #542060] Thu, 24 June 2010 22:28 Go to previous messageGo to next message
Tim is currently offline TimFriend
Messages: 21
Registered: June 2010
Junior Member
And just a bit more information. I've been tracing the code and it seems like we get a DatabaseAccessor.reconnect() for each database call since we use ExternalConnectionPooling (see DatabaseAccessor.incrementCallCount()). So when the system is under load, we are making dozens of calls to DatabaseAccessor.reconnect() and thus JCEEncryptor.decryptPassword() every minute.

So we're making a lot of calls to this and my guess is that since the Cipher calls are not thread safe, we are ending up with an occasional collision, causing the NegativeArraySizeException.

The frustrating part of this is that we are using a JNDI datasource and therefore don't have a password to deal with. But it is still calling this constantly.

I think I may have a workaround to fix this issue, but I think there is an underlying issue with this call being made for each database call and the fact that JCEEncryptor.decryptPassword() is not threadsafe.

I'll let you know if I am able to get this cleared up, but do let me know if you need more details of what I am seeing and/or want me to file an issue.

Thanks.

--Tim
Re: org.eclipse.persistence.exceptions.ValidationException thrown due to NegativeArraySizeException [message #543134 is a reply to message #542462] Mon, 28 June 2010 13:57 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 1039
Registered: July 2009
Senior Member
Hello,

The error is slightly different, but the issue seems similar to the issue in 3927740. Synchronization that was added to fix 3927740 seems to have been removed in the bundle to EclipseLink, so please file a bug to have it fixed and remember to vote for it.

Best Regards,
Chris
Re: org.eclipse.persistence.exceptions.ValidationException thrown due to NegativeArraySizeException [message #543150 is a reply to message #543134] Mon, 28 June 2010 14:55 Go to previous message
Tim is currently offline TimFriend
Messages: 21
Registered: June 2010
Junior Member
Great to hear. I filed a bug, 318187 and voted for it.

I also managed to work around the issue in our code. Seems we were blanking out the password field when using JNDI, but since it was still set (albeit to ""), it was making this call with each DB call. Instead of blanking it out, we are now just not setting it with JNDI, which means we are not calling the code repeatedly, so we're no longer seeing this issue.

--Tim
Previous Topic:Enum literals in JPQL IN expressions
Next Topic:Eclipse Dali Refactoring Participation
Goto Forum:
  


Current Time: Thu Nov 27 14:50:26 GMT 2014

Powered by FUDForum. Page generated in 0.02550 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software