September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (EJBTHREE-326) Some queries are slower when executed in JBoss EJB3

by J-C jc (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-326?page=comments#action_12343797 ] J-C jc commented on EJBTHREE-326: --------------------------------- I had this problem with old release of JBoss EJB3 (rc2). I do not check if it is always true with last release. Problem was that queries was slower inside JBoss AS than using EJB3 persistence outside of JBoss AS (in a standalone application). This issue is probably not the same as http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12340482. Problem is probably in the integration of HEM with the JBoss AS. > Some queries are slower when executed in JBoss EJB3 > --------------------------------------------------- > > Key: EJBTHREE-326 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-326 > Project: EJB 3.0 > Issue Type: Bug > Components: EJB3 Extensions > Affects Versions: EJB 3.0 RC3 > Environment: JBoss4.0.3 rc2 > Reporter: J-C jc > Assigned To: Emmanuel Bernard > > When a lot of objects have been resolved in the current transaction, queries becomes slow. see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=68954&postdays=0... for more details. > More generally, it seems that EJB3 persistence access is slower in JBoss EJB3 compare to access in EJB3 outside of JBoss: > see http://forum.hibernate.org/viewtopic.php?t=948850 -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-545) Transaction edge cases and memory leak

by Tim Fox (JIRA)

Transaction edge cases and memory leak -------------------------------------- Key: JBMESSAGING-545 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.CR4 Reporter: Tim Fox Fix For: 1.0.1.CR5 There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction. We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase). We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback. Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit. In this case the manager may retry the commit, but we will have no record of the branch. Therefore if we receive commits for transactions we know nothing about we should return success. -- 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

19 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBSEAM-308) DataModel instance changes even though the backing list did not when using PAGE scope

by Chris Rudd (JIRA)

DataModel instance changes even though the backing list did not when using PAGE scope ------------------------------------------------------------------------------------- Key: JBSEAM-308 URL: http://jira.jboss.com/jira/browse/JBSEAM-308 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.0.1, 1.0, 1.0 beta 2, 1.0 beta 1, 1.1 Reporter: Chris Rudd The outjectDataModel code attempts to determine if the value changed and therefore needs to be re outjected. When not using PAGE scope this works fine. When PAGE scope is used it always reports dirty, which causes the value to be outjected. The issue is that if the backing value didnt change, it still gets re-wrapped and outjected instead of just re-outjected. I noticed this when working with an @DataModel, the UIData components im using cache the DataModel to ensure that it doesnt change between the updateValues and the invokeApplication phases. So hwat ends up happening is that in the updateValues phase a property gets set on my component, causing the datamodel to be re-outjected, since the UIData has already cached the original value, it never picks up the "new" one. When I get to the invokeApplication phase and it calls an action method on the component the datamodel that the UIData updated the rowIndex on isnt the same one that seam pulls the rowIndex from to inject the @DataModelSelection. I propose the following fix to the 1.0.0 GA code ( removed PAGE scope check from dirty assignment, added else clause to if(dirty) ): private void outjectDataModelList(String name, Object list, ScopeType scope, DataBinder wrapper) { Context context = getDataModelContext(scope); Object existingDataModel = context.get(name); boolean dirty = existingDataModel == null || !wrapper.getWrappedData(existingDataModel).equals(list); //TODO: delegate to the wrapper to determine equality if ( dirty ) { if ( list != null ) { context.set( name, wrapper.wrap(list) ); } else { context.remove( name ); } } // If page scope, outject the existingDataModel even if there was no change else if( scope==ScopeType.PAGE ) { context.set( name, existingDataModel ); } } -- 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

19 years, 10 months

2
3
0 / 0

[JBoss JIRA] Commented: (EJBTHREE-326) Some queries are slower when executed in JBoss EJB3

by Emmanuel Bernard (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-326?page=comments#action_12343793 ] Emmanuel Bernard commented on EJBTHREE-326: ------------------------------------------- We have discovered an important unefficiency (n**2 class) in HEM flush algorithm, do you happen to have lot's of cascade (even bidirectional ones)? > Some queries are slower when executed in JBoss EJB3 > --------------------------------------------------- > > Key: EJBTHREE-326 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-326 > Project: EJB 3.0 > Issue Type: Bug > Components: EJB3 Extensions > Affects Versions: EJB 3.0 RC3 > Environment: JBoss4.0.3 rc2 > Reporter: J-C jc > Assigned To: Emmanuel Bernard > > When a lot of objects have been resolved in the current transaction, queries becomes slow. see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=68954&postdays=0... for more details. > More generally, it seems that EJB3 persistence access is slower in JBoss EJB3 compare to access in EJB3 outside of JBoss: > see http://forum.hibernate.org/viewtopic.php?t=948850 -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (EJBTHREE-553) PrePersist callback method not called if entity's primery key is null

by Mark Menard (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-553?page=comments#action_12343792 ] Mark Menard commented on EJBTHREE-553: -------------------------------------- I'm also having this issue, setting my id in the @PrePersist method, and I'm going to apply Michal's patch to Hibernate to work around it. I would like to ask though is this the way it is supposed to work? Or should we just not generate ids in the @PrePersist method? > PrePersist callback method not called if entity's primery key is null > --------------------------------------------------------------------- > > Key: EJBTHREE-553 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-553 > Project: EJB 3.0 > Issue Type: Bug > Environment: jboss-4.0.4.CR2 > Reporter: Michal Borowiecki > > When an entity is persisted which does not have its primary key set (and it is not annotated with GeneratedValue annotation), the @PrePersist callback method is not invoked. > Instead the exception is thrown: > Caused by: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): com.bluemedia.system.User > at org.hibernate.id.Assigned.generate(Assigned.java:33) > at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:98) > at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131) > at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87) > at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38) > at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:617) > at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:591) > at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:595) > at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:187) > ... 64 more > This is in conflict with ejb 3.0-pfd spec, which states (sec. 3.4.2) : > "The PrePersist and PreRemove callback methods are invoked for a given entity before the respective EntityManager persist and remove operations for that entity are executed." > Since the spec states that EntityManager's persist operation is executed after the PrePersist callback methods, setting the value of the primary key in a PrePersist callback method seems a reasonable use case. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-549) Remoting 2.2.0.Alpha1 breaks 2 crash tests

by Ovidiu Feodorov (JIRA)

Remoting 2.2.0.Alpha1 breaks 2 crash tests ------------------------------------------ Key: JBMESSAGING-549 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-549 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.CR4 Reporter: Ovidiu Feodorov Assigned To: Clebert Suconic Priority: Blocker Fix For: 1.0.1.CR5 1) org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest Error setting up client lease upon performing connect. javax.jms.IllegalStateException: Error setting up client lease upon performing connect. at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91) at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java) at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107) at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java) at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java) at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202) at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96) at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91) at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77) at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695) at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source) at org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest.testClientCrash(ClientCrashNegativeLeaseTest.java:115) 2) org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest Error setting up client lease upon performing connect. javax.jms.IllegalStateException: Error setting up client lease upon performing connect. at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91) at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java) at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107) at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java) at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java) at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202) at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96) at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91) at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77) at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695) at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source) at org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest.testClientCrash(ClientCrashZeroLeaseTest.java:115) -- 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

19 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-551) Upgrade JBoss Remoting

by Clebert Suconic (JIRA)

Upgrade JBoss Remoting ---------------------- Key: JBMESSAGING-551 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-551 Project: JBoss Messaging Issue Type: Task Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.0.1.CR5 Upgrade JBoss Remoting to a version containing JBREM-602 fixed. -- 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

19 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-547) Upgrade JBossSerialization to 1.0.3.GA

by Clebert Suconic (JIRA)

Upgrade JBossSerialization to 1.0.3.GA -------------------------------------- Key: JBMESSAGING-547 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-547 Project: JBoss Messaging Issue Type: Task Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.0.1.CR5 I will do it as soon as the release is out. -- 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

19 years, 10 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker configuration and testing

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ] Ovidiu Feodorov updated JBMESSAGING-207: ---------------------------------------- JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91135 (was: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=74846) > HTTP invoker configuration and testing > -------------------------------------- > > Key: JBMESSAGING-207 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207 > Project: JBoss Messaging > Issue Type: Task > Components: Configuration and Management > Reporter: Ovidiu Feodorov > Assigned To: Ron Sigal > Priority: Blocker > Fix For: 1.0.1.CR5 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Provide a HTTP invoker initial configuration and a working example. > Add the example to docs/examples so it can be used as an integration test. > Reviewed requirements: > 1. The messaging client needs to connect to the server over HTTP > 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously. > 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker configuration and testing

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ] Ovidiu Feodorov updated JBMESSAGING-207: ---------------------------------------- Description: Provide a HTTP invoker initial configuration and a working example. Add the example to docs/examples so it can be used as an integration test. Reviewed requirements: 1. The messaging client needs to connect to the server over HTTP 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously. 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass. was: Provide a HTTP invoker initial configuration and a working example. Add the example to docs/examples so it can be used as an integration test. > HTTP invoker configuration and testing > -------------------------------------- > > Key: JBMESSAGING-207 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207 > Project: JBoss Messaging > Issue Type: Task > Components: Configuration and Management > Reporter: Ovidiu Feodorov > Assigned To: Ron Sigal > Priority: Blocker > Fix For: 1.0.1.CR5 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Provide a HTTP invoker initial configuration and a working example. > Add the example to docs/examples so it can be used as an integration test. > Reviewed requirements: > 1. The messaging client needs to connect to the server over HTTP > 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously. > 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass. -- 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

19 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006