[JBoss JIRA] Created: (JBPORTAL-1152) testsuite problem with sybase
by Prabhat Jha (JIRA)
testsuite problem with sybase
-----------------------------
Key: JBPORTAL-1152
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1152
Project: JBoss Portal
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Prabhat Jha
Assigned To: Roy Russo
During portal testsuite run with sybase database, tables are not getting created successfully. These are two major errors that I see:
1. ERROR [SchemaExport] Unsuccessful: create table jbp_cms_cmsentry (PK int identity not null, FSENTRY_NAME varchar(255) null, FSENTRY_PATH varchar(245) not null, FSENTRY_DATA image nu\ ll, FSENTRY_LASTMOD numeric(19,0) not null, FSENTRY_LENGTH numeric(19,0) not null, primary key (PK))
[junit_] 17:50:33,387 ERROR [SchemaExport] Identity field 'PK' must be a numeric with a scale of 0 and not null allowed.
2. ERROR [SchemaExport] Unsuccessful: create table jbp_cms_version_refs (PK int identity not null, NODE_ID varchar(36) null, REFS_DATA varbinary(100000000) not null, primary key (PK))
[junit_] 17:50:33,413 ERROR [SchemaExport] Length or precision specification 100000000 is not within the range of 1 to 16384.
Assigning it to Roy since you seem to be the most involved with it. ;-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBWEB-75) Contention in ApplicationContext
by Phillip Thurmond (JIRA)
Contention in ApplicationContext
--------------------------------
Key: JBWEB-75
URL: http://jira.jboss.com/jira/browse/JBWEB-75
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss 4.0.5, Linux, Java 5
Reporter: Phillip Thurmond
Assigned To: Mladen Turk
I'm seeing some contention inside Tomcat on ApplicationContext.getAttribute() when I run performance tests using a Seam application. With a load of 200 threads, I often see over 150 "waiting to lock" messages on the attributes object. It looks like this contention has already been fixed in Tomcat 6 using the Java 5 concurrent objects.
I also posted to the Tomcat development list about this issue, but Remy did not want to fix it because he didn't want to introduce any new dependencies into the project. I think this is important to fix if we expect users to deploy Seam on 4.0.5.
Example thread dump:
"http-10.68.0.196-8080-301" daemon prio=1 tid=0x0000002b51e425b0 nid=0x78a5 waiting for monitor entry [0x000000005b86c000..0x000000005b86cdb0]
at org.apache.catalina.core.ApplicationContext.getAttribute(ApplicationContext.java:175)
- waiting to lock <0x0000002aabd633b0> (a java.util.HashMap)
at org.apache.catalina.core.ApplicationContextFacade.getAttribute(ApplicationContextFacade.java:315)
at org.apache.myfaces.context.servlet.ApplicationMap.getAttribute(ApplicationMap.java:41)
at org.apache.myfaces.context.servlet.AbstractAttributeMap.get(AbstractAttributeMap.java:87)
at org.jboss.seam.contexts.FacesApplicationContext.get(FacesApplicationContext.java:47)
at org.jboss.seam.Component.forName(Component.java:1588)
at org.jboss.seam.Component.getInstance(Component.java:1636)
at org.jboss.seam.Component.getInstance(Component.java:1631)
at org.jboss.seam.Component.getInstance(Component.java:1608)
at org.jboss.seam.Component.getInstance(Component.java:1603)
at org.jboss.seam.core.Events.instance(Events.java:158)
at org.jboss.seam.jsf.AbstractSeamPhaseListener.afterPhase(AbstractSeamPhaseListener.java:139)
at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:69)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBWEB-74) tomcat config files fail to support default sysprop values like other jboss-service.xml type configs
by John Mazzitelli (JIRA)
tomcat config files fail to support default sysprop values like other jboss-service.xml type configs
----------------------------------------------------------------------------------------------------
Key: JBWEB-74
URL: http://jira.jboss.com/jira/browse/JBWEB-74
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Reporter: John Mazzitelli
Assigned To: Mladen Turk
>From my JBoss forum post and Dimitris' reply:
In jboss-service.xml, you can define values via properties like this:
${my.prop:123}
where the value will be 123 if and only if my.prop property is not explictly set.
However, this syntax does not seem to work on JBossAS 4.0.5 within the jbossweb-tomcat55.sar's server.xml.
If I use ${my.prop} in server.xml, it works fine. But if I define a default value like ${my.prop:123}, it doesn't work - the value becomes literally ${my.prop}.
Dimitris Andreadis reply: "JBoss uses org.jboss.util.StringPropertyReplacer for substituting variables. Tomcat/jboss-web must be using a different way to do this, so this is really a feature request for jboss-web."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JASSIST-30) Memory Leak - failure to clean up javassisst instances after EJB3 remote calls
by Grant Quimby (JIRA)
Memory Leak - failure to clean up javassisst instances after EJB3 remote calls
------------------------------------------------------------------------------
Key: JASSIST-30
URL: http://jira.jboss.com/jira/browse/JASSIST-30
Project: Javassist
Issue Type: Bug
Environment: JBoss 4.0.4.GA, Windows Xp
JBoss 4.0.4.GA, LInux (Debian)
JBoss 4.0.4.GA, Solaris
Reporter: Grant Quimby
Assigned To: Shigeru Chiba
Priority: Blocker
Quote from related JIRA issue EJBTHREE-736
PermGen in EJB3 client aplication by remote interface.
The application is as sample as it can be:
-get remote interface of stateless EJB3 (by JNDI)
- ask 1000 times to get a Collection (List) of 10 EntityBeans.
After 255 there is OutOfMemory: PermGen.
JVM options changes nothing (eventualy more PermSpace => longer run).
The reason looks like the Javassist create lazyinitializer classes for every EntityBean retrived from the server.
So: When I debug on server-side, I got before sending Entity to client:
I got:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_7> 13434
...
myEntity[0].user=<UserEntity_$$_javassist_15>...
myEntity[0].stage=<StageEntity_$$_javassist_17>...
And every remote call the class names (name)_$..._javassist_(index) got the same
indexes (7,15,17) on server side (end every entity in returned collections of entities)
But when I debug on client site - after return from remote call - the indexes of
all returned entities are different (Each next increments index).
So after first call I got:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_0>...
...
myEntity[0].user=<UserEntity_$$_javassist_1>...
myEntity[0].stage=<StageEntity_$$_javassist_2>...
...
myEntity[1].id=143534
myEntity[1].flow=<FlowEntity_$$_javassist_3>
...
myEntity[1].user=<UserEntity_$$_javassist_4>...
myEntity[1].stage=<StageEntity_$$_javassist_5>...
...
After secund call:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_6>...
...
myEntity[0].user=<UserEntity_$$_javassist_7>...
myEntity[0].stage=<StageEntity_$$_javassist_8>...
...
myEntity[1].id=143534
myEntity[1].flow=<FlowEntity_$$_javassist_9>
...
myEntity[1].user=<UserEntity_$$_javassist_10>...
myEntity[1].stage=<StageEntity_$$_javassist_11>...
...
And so on... ... and permGen after 260 iterations...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JASSIST-28) javassist enhancement failed on deserializing hibernate proxies
by Armin Haaf (JIRA)
javassist enhancement failed on deserializing hibernate proxies
---------------------------------------------------------------
Key: JASSIST-28
URL: http://jira.jboss.com/jira/browse/JASSIST-28
Project: Javassist
Issue Type: Bug
Environment: hibernate 3.2.0GA, javassist 3.3, jboss 4.0.4GA
Reporter: Armin Haaf
Assigned To: Shigeru Chiba
on deserializing objects load by hibernate on a jbossas with uninitialized proxies we the following exception on a performance/concurrent testing:
Exception in thread "Thread-7" org.hibernate.HibernateException: Javassist Enhancement failed: de.mueller.wms.base.model.impl.StorageImpl
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(JavassistLazyInitializer.java:88)
at org.hibernate.proxy.pojo.javassist.SerializableProxy.readResolve(SerializableProxy.java:54)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1033)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1728)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279)
at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
at org.jboss.remoting.Client.invoke(Client.java:525)
at org.jboss.remoting.Client.invoke(Client.java:488)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
at $Proxy2.executeCommand(Unknown Source)
at de.mueller.wms.base.service.JndiRemoteLookupDelegateImpl$CommandExecutionInvocationHandler.invoke(JndiRemoteLookupDelegateImpl.java:57)
at $Proxy1.changeStock(Unknown Source)
at de.mueller.wms.base.TestJBossPerformance$1.run(TestJBossPerformance.java:58)
Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate class definition: de/mueller/wms/base/model/impl/StorageImpl_$$_javassist_1272
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(JavassistLazyInitializer.java:79)
... 44 more
Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicate class definition: de/mueller/wms/base/model/impl/StorageImpl_$$_javassist_1272
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:167)
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:170)
... 45 more
Caused by: java.lang.LinkageError: duplicate class definition: de/mueller/wms/base/model/impl/StorageImpl_$$_javassist_1272
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159)
... 46 more
The performance is also very bad in comparison with cglib proxies (in our performance test with cglib proxies the test runs 3x faster)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBCACHE-811) Use InvocationContext to avoid multiple searches for a node
by Brian Stansberry (JIRA)
Use InvocationContext to avoid multiple searches for a node
-----------------------------------------------------------
Key: JBCACHE-811
URL: http://jira.jboss.com/jira/browse/JBCACHE-811
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Manik Surtani
When an interceptor finds a node, why not throw it in the InvocationContext or something similar and pass it through the stack that way? Subsequent calls to find the node can check the context first before walking the cache tree. Saves redundant walking of the tree.
We'd need to think very carefully about this, as it exposes 2 paths to access a node -- from a thread's context and from the tree. Need to ensure concurrent threads always access the same node object for a given Fqn.
(Side thought -- perhaps disable this for weak isolation levels where the locking behavior in the interceptors make it possible to end up w/ 2 concurrent nodes for the same Fqn).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBCLUSTER-150) CNFE issues with Hibernate and JBoss Cache
by Brian Stansberry (JIRA)
CNFE issues with Hibernate and JBoss Cache
------------------------------------------
Key: JBCLUSTER-150
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-150
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: Q4Y6
Hibernate w/ JBC as 2nd level cache can potentially place instances of custom user classes in the cache. Can happen if the query cache is used, since instances of custom classes can be parameters to queries.
This leads to replication or state transfer problems like the following if the custom classes are not visible to JBC's classloader (i.e. the custom classes aren't in server/all/lib). For regular entity caching, Hibernate stores primitives in the cache, so this is less of an issue. Problem is more with the query cache.
java.lang.ClassNotFoundException: No ClassLoaders found for: services.entities.ProductDemandPK
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:511)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:585)
at org.jboss.invocation.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.j
ava:109)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.cache.Fqn.readExternal(Fqn.java:355)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.cache.loader.NodeData.readExternal(NodeData.java:59)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:241)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:271)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:271)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:271)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateTransientState(StateTr
ansferIntegrator_140.java:222)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateTransientState(StateTr
ansferIntegrator_140.java:97)
at org.jboss.cache.TreeCache._setState(TreeCache.java:2640)
at org.jboss.cache.TreeCache.access$000(TreeCache.java:86)
at org.jboss.cache.TreeCache$MessageListenerAdaptor.setState(TreeCache.java:5306)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:614)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:331)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:55
4)
at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
at java.lang.Thread.run(Thread.java:595)
JBC's region-based marshalling API is meant for dealing with this kind of thing. Need to see how Hibernate can be configured to work with this API. Expect this will lead to JIRAs in the Hibernate and possible EBJ3 project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 10 months