[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 6/28/17 5:17 AM:
----------------------------------------------------------------------
Hi,
It is a bit hard for me to keep up.
But I see the point.
It is not a trivial matter manage the sequence by which Synchronization Listeners register on the transaction.
But I would agree, that one way or another, somehow the eclipselink:
org.eclipse.persistence.transaction.JTASynchronizationListener
Needs to be run before the CDI on completion synchronization listener.
Side Notes:
- I am trying take a pick the eclipse link code related to the synchronization process.
Here are some of the relevant classes:
(a) org.eclipse.persistence.transaction.JTATransactionController
This class is extended by multiple subclasses, specific to different application servers.
Among its apis it holds the method:
registerSynchronization_impl
QUOTE
{panel}
/**
* INTERNAL:
* Register the specified synchronization listener with the given active
* transaction.
*
* @param listener The synchronization listener created for this transaction
* @param txn The active transaction for which notification is being requested
*/
protected void registerSynchronization_impl(AbstractSynchronizationListener listener, Object txn) throws Exception {
((Transaction)txn).registerSynchronization((Synchronization)listener);
}
{panel}
And here we know that the registration will be happening too late.
With the WildflyServerPlaform, it would like the ideal thing would be if the inner class:
org.jipijapa.eclipselink.WildFlyServerPlatform.JBossAS7TransactionController
Could somehow override the registerSynchronization_impl to ensure that when it registers it goes to earlies position on the list.
But I doubt there are public APIs for doing this level of tunning.
The class
org.eclipse.persistence.internal.jpa.EntityManagerImpl
Is that class that will go down the rabit hole, until the JTA synchronization registration listener is put in place in its:
org.eclipse.persistence.internal.jpa.EntityManagerImpl.getActivePersistenceContext(Object)
{panel}
if (txn != null) {
// if there is a txn, it means we have been marked to join with it.
// All that is left is to register the UOW with the transaction
transaction.registerIfRequired(this.extendedPersistenceContext);
}
{panel}
I could imagine the following Possbility 1,
That I could call a "vodoo" work-around.
Ant that most likely is no feasible as explained bellow.
At time 1, when Wildfly registers the normal CDI Dummy synchronization listener - DelayedCDIObserverSynchronizationListenerr or something of the sort
At time 2, the arjuna is going over registered listeners and invoking them
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(int) line: 96
At time 3, the DelayedCDIObserverSynchronizationListenerr
gets called and it makes a late registrations into the transaction of the real CDI listener that is currently being invoked in first place.
At time 4, the eclipselink
org.eclipse.persistence.transaction.JTASynchronizationListener
At time 5, the real CDI Observer notifier gets invoked since it was "vodoo" placed into the trasaction at the alst posisble moment in time.
I can well imagine that this sort of work-around might not even be technically possible since it would verily likely lead to something like at concurrent modification exceptions on the:
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(int) line: 96
As we goes out of invoking the listener, and tries to move to the next one, the list is suddenly changed and the loop broken.
But the fact is that the:
javax.transaction.Transaction registerSynchronization seems to give no option on sorting the order of the observers.
Also seems not to give any option to remove the observers.
Therefore a cleaner Possibility 2 (might not be posisblle as well:
One would want to override method of:
registerSynchronization_impl
And write it to be something as simple as:
To (a) Get a list of all registered observers.
(b) Derisgeter them all
(c) Register the eclipselink obverserver first on the list
(d) Ad all of the de-registered observers back in.
Kindest regards.
was (Author: nuno.godinhomatos):
Hi,
It is a bit hard for me to keep up.
But I see the point.
It is not a trivial matter manage the sequence by which Synchronization Listeners register on the transaction.
But I would agree, that one way or another, somehow the eclipselink:
org.eclipse.persistence.transaction.JTASynchronizationListener
Needs to be run before the CDI on completion synchronization listener.
Side Notes:
- I am trying take a pick the eclipse link code related to the synchronization process.
Here are some of the relevant classes:
(a) org.eclipse.persistence.transaction.JTATransactionController
This class is extended by multiple subclasses, specific to different application servers.
Among its apis it holds the method:
registerSynchronization_impl
QUOTE
{panel}
/**
* INTERNAL:
* Register the specified synchronization listener with the given active
* transaction.
*
* @param listener The synchronization listener created for this transaction
* @param txn The active transaction for which notification is being requested
*/
protected void registerSynchronization_impl(AbstractSynchronizationListener listener, Object txn) throws Exception {
((Transaction)txn).registerSynchronization((Synchronization)listener);
}
{panel}
And here we know that the registration will be happening too late.
With the WildflyServerPlaform, it would like the ideal thing would be if the inner class:
org.jipijapa.eclipselink.WildFlyServerPlatform.JBossAS7TransactionController
Could somehow override the registerSynchronization_impl to ensure that when it registers it goes to earlies position on the list.
But I doubt there are public APIs for doing this level of tunning.
The class
org.eclipse.persistence.internal.jpa.EntityManagerImpl
Is that class that will go down the rabit hole, until the JTA synchronization registration listener is put in place in its:
org.eclipse.persistence.internal.jpa.EntityManagerImpl.getActivePersistenceContext(Object)
{panel}
if (txn != null) {
// if there is a txn, it means we have been marked to join with it.
// All that is left is to register the UOW with the transaction
transaction.registerIfRequired(this.extendedPersistenceContext);
}
{panel}
I could imagine the following "vodoo" work-around.
At time 1, when Wildfly registers the normal CDI Dummy synchronization listener - DelayedCDIObserverSynchronizationListenerr or something of the sort
At time 2, the arjuna is going over registered listeners and invoking them
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(int) line: 96
At time 3, the DelayedCDIObserverSynchronizationListenerr
gets called and it makes a late registrations into the transaction of the real CDI listener that is currently being invoked in first place.
At time 4, the eclipselink
org.eclipse.persistence.transaction.JTASynchronizationListener
At time 5, the real CDI Observer notifier gets invoked since it was "vodoo" placed into the trasaction at the alst posisble moment in time.
I can well imagine that this sort of work-around might not even be technically possible since it would verily likely lead to something like at concurrent modification exceptions on the:
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(int) line: 96
As we goes out of invoking the listener, and tries to move to the next one, the list is suddenly changed and the loop broken.
But the fact is that the:
javax.transaction.Transaction registerSynchronization seems to give no option on sorting the order of the observers.
Also seems not to give any option to remove the observers.
So it would also not be possible for an orverriding method of:
registerSynchronization_impl
To (a) Get a list of all registered observers.
(b) Derisgeter them all
(c) Register the eclipselink obverserver first on the list
(d) Ad all of the de-registered observers back in.
Kindest regards.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9014) Second remote EJB client connection prevents server from shutting down (Elytron, Remoting)
by Josef Cacek (JIRA)
Josef Cacek created WFLY-9014:
---------------------------------
Summary: Second remote EJB client connection prevents server from shutting down (Elytron, Remoting)
Key: WFLY-9014
URL: https://issues.jboss.org/browse/WFLY-9014
Project: WildFly
Issue Type: Bug
Components: EJB, Remoting, Security
Reporter: Josef Cacek
Assignee: David Lloyd
Priority: Blocker
Second call of EJB client causes server stuck in some cases. When this happens administrator is not able to shutdown or reload such a server.
*Scenario details:*
Elytron is configured as security provider on servers and Elytron client API is used for authentication. Protected stateless beans are used.
{noformat}
EJB Client -> Entry bean on Server1 -> WhoAmI bean on Server2
{noformat}
* Client uses {{AuthenticationConfiguration}} with valid credentials for Server1; Client calls the Entry bean twice - the difference is in arguments provided. The arguments are subsequently used for authentication from Server1 to Server2 (using AuthenticationConfiguration):
** first call uses null for both username and password
** second call uses valid credentials for Server2
* Entry bean on Server1 calls WhoAmI bean on Server2 with credentials which was provided as method arguments;
* WhoAmI bean on Server2 just returns caller principal
The Client is executed twice, the second call doesn't finish
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8852) Clean up managed domain handling of the transaction subsystem's 'probe' operation
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/WFLY-8852?page=com.atlassian.jira.plugin.... ]
Michael Musgrove resolved WFLY-8852.
------------------------------------
Resolution: Done
Was fixed by commit 399b88af2c,
> Clean up managed domain handling of the transaction subsystem's 'probe' operation
> ---------------------------------------------------------------------------------
>
> Key: WFLY-8852
> URL: https://issues.jboss.org/browse/WFLY-8852
> Project: WildFly
> Issue Type: Sub-task
> Components: Transactions
> Reporter: Brian Stansberry
> Assignee: Michael Musgrove
>
> Subtask for this item from the parent issue:
> {quote}
> The transaction subsystem's "probe" operation. A read-only, runtime-only op registered on the profile resource but which is functionally a no-op if invoked on the profile resource. But WFCORE-2858 would mean this now gets rolled out to all servers in the domain that use the profile, triggering an actual probe on all. So, if we do WFCORE-2858 we could:
> a) Accept this, and let the op roll out. That should be an RFE though, with analysis that rolling it out would be harmless.
> b) Remove the op from the profile. It never did anything useful (just a no-op that isn't rolled out) so removing it is only
> a semi-breaking change.
> c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
> Choice c) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) and b) still options for the future, so that's what will be done as part of this work.
> {quote}
> The parent issue will do choice c); this issue is to decide the final status.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9013) Upgrade Generic JMS RA 2.0.0.Final
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-9013?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-11824 to WFLY-9013:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9013 (was: JBEAP-11824)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: Generic JMS RA)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.ER1)
> Upgrade Generic JMS RA 2.0.0.Final
> ----------------------------------
>
> Key: WFLY-9013
> URL: https://issues.jboss.org/browse/WFLY-9013
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> I think as we are moving closer to GA, generic RA bits shouldn't be named alpha any more.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1635) InMemorySessionFactory has apparent memory leak
by Hiroko Miura (JIRA)
Hiroko Miura created DROOLS-1635:
------------------------------------
Summary: InMemorySessionFactory has apparent memory leak
Key: DROOLS-1635
URL: https://issues.jboss.org/browse/DROOLS-1635
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.5.0.Final
Reporter: Hiroko Miura
Assignee: Maciej Swiderski
I'm running drools with a runtime manager creating using PerRequest strategy and SessionCache turned on. (I process a LOT of requests but I want each one to be isolated)
The SessionCache properly gets rid of sessions that have hung around too long, which is great.
But the InMemorySessionFactory keeps a copy of every session it ever created, which -- it seems to me -- impedes garbage collection of unneeded, old sessions.
It's possible I'm just reading this wrong, but examinations of running code using VisualVM show a LOT of RightTuple objects hanging around, attached to sessions and their GC root appears to be the InMemorySessionFactory.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------
Hi,
It is a bit hard for me to keep up.
But I see the point.
It is not a trivial matter manage the sequence by which Synchronization Listeners register on the transaction.
But I would agree, that one way or another, somehow the eclipselink:
org.eclipse.persistence.transaction.JTASynchronizationListener
Needs to be run before the CDI on completion synchronization listener.
Side Notes:
- I am trying take a pick the eclipse link code related to the synchronization process.
Here are some of the relevant classes:
(a) org.eclipse.persistence.transaction.JTATransactionController
This class is extended by multiple subclasses, specific to different application servers.
Among its apis it holds the method:
registerSynchronization_impl
QUOTE
{panel}
/**
* INTERNAL:
* Register the specified synchronization listener with the given active
* transaction.
*
* @param listener The synchronization listener created for this transaction
* @param txn The active transaction for which notification is being requested
*/
protected void registerSynchronization_impl(AbstractSynchronizationListener listener, Object txn) throws Exception {
((Transaction)txn).registerSynchronization((Synchronization)listener);
}
{panel}
And here we know that the registration will be happening too late.
With the WildflyServerPlaform, it would like the ideal thing would be if the inner class:
org.jipijapa.eclipselink.WildFlyServerPlatform.JBossAS7TransactionController
Could somehow override the registerSynchronization_impl to ensure that when it registers it goes to earlies position on the list.
But I doubt there are public APIs for doing this level of tunning.
The class
org.eclipse.persistence.internal.jpa.EntityManagerImpl
Is that class that will go down the rabit hole, until the JTA synchronization registration listener is put in place in its:
org.eclipse.persistence.internal.jpa.EntityManagerImpl.getActivePersistenceContext(Object)
{panel}
if (txn != null) {
// if there is a txn, it means we have been marked to join with it.
// All that is left is to register the UOW with the transaction
transaction.registerIfRequired(this.extendedPersistenceContext);
}
{panel}
I could imagine the following "vodoo" work-around.
At time 1, when Wildfly registers the normal CDI Dummy synchronization listener - DelayedCDIObserverSynchronizationListenerr or something of the sort
At time 2, the arjuna is going over registered listeners and invoking them
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(int) line: 96
At time 3, the DelayedCDIObserverSynchronizationListenerr
gets called and it makes a late registrations into the transaction of the real CDI listener that is currently being invoked in first place.
At time 4, the eclipselink
org.eclipse.persistence.transaction.JTASynchronizationListener
At time 5, the real CDI Observer notifier gets invoked since it was "vodoo" placed into the trasaction at the alst posisble moment in time.
I can well imagine that this sort of work-around might not even be technically possible since it would verily likely lead to something like at concurrent modification exceptions on the:
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(int) line: 96
As we goes out of invoking the listener, and tries to move to the next one, the list is suddenly changed and the loop broken.
But the fact is that the:
javax.transaction.Transaction registerSynchronization seems to give no option on sorting the order of the observers.
Also seems not to give any option to remove the observers.
So it would also not be possible for an orverriding method of:
registerSynchronization_impl
To (a) Get a list of all registered observers.
(b) Derisgeter them all
(c) Register the eclipselink obverserver first on the list
(d) Ad all of the de-registered observers back in.
Kindest regards.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months