[JBoss JIRA] (AS7-2968) @PreUpdate entity callback not running in caller's context when Container Managed Transactions are used
by Nicholas Fleury (JIRA)
[ https://issues.jboss.org/browse/AS7-2968?page=com.atlassian.jira.plugin.s... ]
Nicholas Fleury commented on AS7-2968:
--------------------------------------
Its the jndi lookup: 'java:comp/EJBContext' always returns null on @PreUpdate.
As this issue was marked as fixed I did not used the workaround mentionned above
> @PreUpdate entity callback not running in caller's context when Container Managed Transactions are used
> -------------------------------------------------------------------------------------------------------
>
> Key: AS7-2968
> URL: https://issues.jboss.org/browse/AS7-2968
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, JPA / Hibernate
> Affects Versions: 7.1.0.Beta1
> Reporter: Juerg Weilenmann
> Assignee: jaikiran pai
> Fix For: 7.1.0.CR1
>
>
> If an Entity Bean has a @PreUpdate listener, the listener is not called in the context of the caller (session bean) in case of Container Managed Transactions.
> As a result, an jndi lookup in the callback for 'java:comp/EJBContext' returns always null. The @PreUpdate callback should run in the context of the caller.
> {noformat}
> @Entity
> @EntityListeners({ MyListener.class })
> public class MyEntity {
> ...
> }
> {noformat}
> {noformat}
> public class MyListener {
>
> @PreUpdate
> @PrePersist
> public void onEntityCallback(Object entity) {
> EJBContext ctx;
>
> ctx = createInitialContext().lookup("java:comp/EJBContext");
> System.out.println(ctx.getCallerPrincipal().getName());
> }
> }
> {noformat}
> {noformat}
> @Stateless
> public class MyServiceBean implements MyServiceRemote {
> @Override
> public void updateEntity(MyEntity entity) {
> entityManager.merge(entity);
> }
> }
> {noformat}
> This listener works fine on @PrePersist (Container- and Bean Managed Transactions) but fails on @PreUpdate with a NullPointerException if container managed transactions are used.
> Workaround: use User Transactions instead of Container Managed Transactions
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JGRP-1659) deadlock in MFC with default configuration
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1659?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1659:
--------------------------------
OK, I ran the test on my Linux box and my mac, with Infinispan 5.2.4.Final and JGroups 3.2.7.Final, and they all passed. I re-ran multiple time, not a single block.
> deadlock in MFC with default configuration
> ------------------------------------------
>
> Key: JGRP-1659
> URL: https://issues.jboss.org/browse/JGRP-1659
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.7
> Reporter: Mircea Markus
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: expiration-test.zip
>
>
> MFC.down does the following:
> {code:java}
> credits.decrement(length, block_time); //A
> if(needToSendCreditRequest()) //B
> sendCreditRequest(tuple.getVal1(), Math.min(max_credits)
> {code}
> A blocks forever even if the MFC.max_block_time is configured:
> {code:xml}
> <MFC max_credits="200k" min_threshold="0.20" max_block_time="1"/>
> {code}
> This happens at the same time on the whole cluster. B never gets invoked, so both wake up conditions( credits received or timeout) for credits.decrement are never satisfied resulting in the whole cluster to freeze.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (WFLY-87) Fired object messages violate classloaders
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-87?page=com.atlassian.jira.plugin.sy... ]
jaikiran pai edited comment on WFLY-87 at 7/18/13 3:39 AM:
-----------------------------------------------------------
There hasn't been an update on the reproducibility of this issue against latest nightly builds. As a result, this issue has been moved around to different target/fix versions. I think we should just resolve this as out-of-date. If this is still an issue against the latest release WildFly version or the nightly build, please provide a relevant application which reproduces it.
was (Author: jaikiran):
There's hasn't been an update on the reproducibility of this issue against latest nightly builds. As a result, this issue has been moved around to different target/fix versions. I think we should just resolve this as out-of-date. If this is still an issue against the latest release WildFly version or the nightly build, please provide a relevant application which reproduces it.
> Fired object messages violate classloaders
> ------------------------------------------
>
> Key: WFLY-87
> URL: https://issues.jboss.org/browse/WFLY-87
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: John Ament
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Beta1
>
> Attachments: test.zip
>
>
> JMS allows you to fire an object message. In this case, I have a object of type in my deployment. It fires fine. I bind a message consumer to a queue in AS7. the object message coming in results in a classloader violation:
> 22:13:35,116 ERROR [org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB] (Thread-2 (group:HornetQ-client-global-threads-767046602)) org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]: javax.jms.JMSException: org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> at java.lang.Class.forName0(Native Method) [:1.6.0_22]
> at java.lang.Class.forName(Class.java:247) [:1.6.0_22]
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_22]
> at org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:69) [hornetq-core-2.2.6.Final.jar:]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_22]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_22]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_22]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_22]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_22]
> at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:158) [hornetq-jms-2.2.6.Final.jar:]
> at org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB.onMessage(DistributorMDB.java:46)
> at org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91) [hornetq-jms-2.2.6.Final.jar:]
> at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:866) [hornetq-core-2.2.6.Final.jar:]
> at org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:44) [hornetq-core-2.2.6.Final.jar:]
> at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:983) [hornetq-core-2.2.6.Final.jar:]
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.6.Final.jar:]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (WFLY-87) Fired object messages violate classloaders
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-87?page=com.atlassian.jira.plugin.sy... ]
jaikiran pai commented on WFLY-87:
----------------------------------
There's hasn't been an update on the reproducibility of this issue against latest nightly builds. As a result, this issue has been moved around to different target/fix versions. I think we should just resolve this as out-of-date. If this is still an issue against the latest release WildFly version or the nightly build, please provide a relevant application which reproduces it.
> Fired object messages violate classloaders
> ------------------------------------------
>
> Key: WFLY-87
> URL: https://issues.jboss.org/browse/WFLY-87
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: John Ament
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Beta1
>
> Attachments: test.zip
>
>
> JMS allows you to fire an object message. In this case, I have a object of type in my deployment. It fires fine. I bind a message consumer to a queue in AS7. the object message coming in results in a classloader violation:
> 22:13:35,116 ERROR [org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB] (Thread-2 (group:HornetQ-client-global-threads-767046602)) org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]: javax.jms.JMSException: org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> at java.lang.Class.forName0(Native Method) [:1.6.0_22]
> at java.lang.Class.forName(Class.java:247) [:1.6.0_22]
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_22]
> at org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:69) [hornetq-core-2.2.6.Final.jar:]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_22]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_22]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_22]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_22]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_22]
> at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:158) [hornetq-jms-2.2.6.Final.jar:]
> at org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB.onMessage(DistributorMDB.java:46)
> at org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91) [hornetq-jms-2.2.6.Final.jar:]
> at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:866) [hornetq-core-2.2.6.Final.jar:]
> at org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:44) [hornetq-core-2.2.6.Final.jar:]
> at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:983) [hornetq-core-2.2.6.Final.jar:]
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.6.Final.jar:]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JGRP-1659) deadlock in MFC with default configuration
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1659?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1659:
--------------------------------
Works fine, even on my mac. I used Infinispan 5.3.0.Final and JGroups 3.3.3.Final, will now try with Infinispan 5.2.4.Final.
> deadlock in MFC with default configuration
> ------------------------------------------
>
> Key: JGRP-1659
> URL: https://issues.jboss.org/browse/JGRP-1659
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.7
> Reporter: Mircea Markus
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: expiration-test.zip
>
>
> MFC.down does the following:
> {code:java}
> credits.decrement(length, block_time); //A
> if(needToSendCreditRequest()) //B
> sendCreditRequest(tuple.getVal1(), Math.min(max_credits)
> {code}
> A blocks forever even if the MFC.max_block_time is configured:
> {code:xml}
> <MFC max_credits="200k" min_threshold="0.20" max_block_time="1"/>
> {code}
> This happens at the same time on the whole cluster. B never gets invoked, so both wake up conditions( credits received or timeout) for credits.decrement are never satisfied resulting in the whole cluster to freeze.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JGRP-1659) deadlock in MFC with default configuration
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1659?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1659:
--------------------------------
Ray,
can I get access to the RHEL box (is it in the lab) ?
As I said, I can run it many times on my Linux box, and it has blocked *exactly 0 times* !
To be honest, I would also be surprised if MFC blocked as it has been in operation *in production* for quite a while now and I have yet to get a report about MFC locking up.
I can run MPerf with a couple of nodes and each node sending 100 million multicast messages, without MFC ever blocking.
I'm trying this on my mac now...
> deadlock in MFC with default configuration
> ------------------------------------------
>
> Key: JGRP-1659
> URL: https://issues.jboss.org/browse/JGRP-1659
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.7
> Reporter: Mircea Markus
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: expiration-test.zip
>
>
> MFC.down does the following:
> {code:java}
> credits.decrement(length, block_time); //A
> if(needToSendCreditRequest()) //B
> sendCreditRequest(tuple.getVal1(), Math.min(max_credits)
> {code}
> A blocks forever even if the MFC.max_block_time is configured:
> {code:xml}
> <MFC max_credits="200k" min_threshold="0.20" max_block_time="1"/>
> {code}
> This happens at the same time on the whole cluster. B never gets invoked, so both wake up conditions( credits received or timeout) for credits.decrement are never satisfied resulting in the whole cluster to freeze.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (WFLY-272) Internal/Redundant information stored in Domain Model
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-272?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated WFLY-272:
--------------------------------
Fix Version/s: (was: 8.0.0.Beta1)
> Internal/Redundant information stored in Domain Model
> -----------------------------------------------------
>
> Key: WFLY-272
> URL: https://issues.jboss.org/browse/WFLY-272
> Project: WildFly
> Issue Type: Feature Request
> Components: ConfigAdmin
> Reporter: Thomas Diesler
>
> Only property 'foo' should show up in the model. Property service.pid is redundant, service.bundleLocation,.org.jboss.source is for internal use only and should not survive shutdown
> {code}
> <configuration pid="org.jboss.as.test.integration.osgi.api.ConfiguredService">
> <property name="service.pid" value="org.jboss.as.test.integration.osgi.api.ConfiguredService"/>
> <property name="service.bundleLocation" value="config-admin-bundle-a"/>
> <property name="foo" value="bar"/>
> <property name=".org.jboss.source" value="notfromdmr"/>
> </configuration>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years