[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 Scott,
I have done as recommended.
https://github.com/99sono/wildfly/commit/dd29331a9b0270fcb0e1e3d0f9d6a811...
You are essentially explaining that the java:jboss/TransactionSynchronizationRegistry is "technically" more readily available to use than the objects that are (aliased) into the java:comp namespace. Did I understand it correctly?
I will read the instructions on the document and make the pull request.
// NOTE: I have started trying to investigate that problem with eclipselink trying to return a used connection to the connection manager, and the connection manager reporting it has no clue what connection is being returned. I have increased the logging level on "org.jboss.jca.core.tracer.Tracer" - I have the feeling that the connectionmanager.ccm.CachedConnectionManager is somehow losing the reference to the connection. Unfortunately, in a small sample application where I tried to reproduce the firing of the event, oserving the event on new transaction and so on ... everything went out perfectly. Could not make it happen. But based on the log file, I see that the flow of statements:
{panel}
####2017-09-02 13:18:28,282 ThreadId:321 ALL connectionmanager.ccm.CachedConnectionManager - registering connection from connection manager: org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl@fdf6032, connection : org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@73598cd4, key: org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction@76d9d984 <LogContext:Facade> <ServerService Thread Pool -- 173>
{panel}
And later:
{panel}
####2017-09-02 13:18:30,655 ThreadId:321 ALL connectionmanager.ccm.CachedConnectionManager - unregistering connection from connection manager: org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl@fdf6032, connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@73598cd4, key: org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction@76d9d984 <LogContext:Facade> <ServerService Thread Pool -- 173>
{panel}
Only appear once each. And it is during this unregister that the blow up happens. So it looks as if in the in between time after the "registering" the connection manager simply lost track of the connection.
I will have to open a JIRA for this, I suppose. I want to investigate it a bit more, but I have very little time avalable to play around this.
I will let you know as soon as the pull request is sent out.
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)
6 years, 8 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on WFCORE-3210 at 9/2/17 6:43 AM:
-----------------------------------------------------------------------
Hi just a side note.
The JUL to Log4j router whose source code you have in the artifacts I have provided you still has some bugs.
- 1 - The JUL log level to Log4j level mapping is bugy.
The JUL log Level OFF shuld be mapped to the Log4j log Level ALL.
In Log4j log level OFF is the highest rank possible, above Fatal, and it is only to be used to qualify categories and never to be used to produce log statements. when using log4j, someone who uses OFF to log statements is doing something completely wrong. It is making those log statements become impossible to filter out.
This bug leads to the fact that if configure the logging susystem to trace IRON JAC AMAR - which I am trying to debug right now, this is producing on many layers log statements with level OFF. I was wondering why I could not filter them out until I realized this.
so JUL.OFF -> Log4j.OFF it is a definite NOGO.
- 2 - In the cove version you have, you will have double logging of a LogRecord, whenever that log record does not come with any MDC context. I was missing a return statement.
So you will see every log event logged twice.
These bugs however should not matter for this Jira, since the theme here is occasional problematic isolation of the custom appender during startup - making the appender useless.
Many thanks.
was (Author: nuno.godinhomatos):
Hi just a side note.
The JUL to Log4j router whose source code you have in the artifacts I have provided you still has some bugs.
- 1 - The JUL log level to Log4j level mapping is bugy.
The JUL log Level OFF shuld be mapped to the Log4j log Level ALL.
In Log4j log level OFF is the highest rank possible, above Fatal, and it is only to be used to qualify categories and never to be used to produce log statements. Someone who uses OFF to log statements does not know what he is doing.
This bug leads to the fact that IRON JAC AMAR - which I am trying to debug, is producing on many layers log statements with level OFF.
I was wondering why I could not filter them out until I realized this.
- 2 - In the cove version you have, you will have double logging of a LogRecord, whenever that log record does not come with any MDC context. I was missing a return statement.
So you will see every log event logged twice.
These bugs however should not matter for this Jira, since the theme here is occasional problematic isolation of the custom appender during startup - making the appender useless.
Many thanks.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on WFCORE-3210 at 9/2/17 6:40 AM:
-----------------------------------------------------------------------
Hi just a side note.
The JUL to Log4j router whose source code you have in the artifacts I have provided you still has some bugs.
- 1 - The JUL log level to Log4j level mapping is bugy.
The JUL log Level OFF shuld be mapped to the Log4j log Level ALL.
In Log4j log level OFF is the highest rank possible, above Fatal, and it is only to be used to qualify categories and never to be used to produce log statements. Someone who uses OFF to log statements does not know what he is doing.
This bug leads to the fact that IRON JAC AMAR - which I am trying to debug, is producing on many layers log statements with level OFF.
I was wondering why I could not filter them out until I realized this.
- 2 - In the cove version you have, you will have double logging of a LogRecord, whenever that log record does not come with any MDC context. I was missing a return statement.
So you will see every log event logged twice.
These bugs however should not matter for this Jira, since the theme here is occasional problematic isolation of the custom appender during startup - making the appender useless.
Many thanks.
was (Author: nuno.godinhomatos):
Hi just a side note.
The JUL to Log4j router whose source code you have in the artifacts I have provided you still has some bugs.
- 1 - The JUL log level to Log4j level mapping is bugy.
The JUL log Level OFF shuld be mapped to the Log4j log Level ALL.
In Log4j log level OFF is the highest rank possible, above Fatal, and it is only to be used to qualify categories and never to be used to produce log statements. Someone who uses OFF to log statements does not know what he is doing.
This bug leads to the fact that IRON JAC AMAR - which I am trying to debug, is producing on many layers log statements with level OFF.
I was wondering why I could not filter them out until I realized this.
- 2 - In the cove version you have, you will have double logging of a LogRecord, whenever that log record does not come with any MDC context. I was missing a return statement.
So you will see every log event logged twice.
These bugs however should not matter for this Jira, since the theme here is occasional problematic startup of wildfly.
Many thanks.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3210:
-----------------------------------------------
Hi just a side note.
The JUL to Log4j router whose source code you have in the artifacts I have provided you still has some bugs.
- 1 - The JUL log level to Log4j level mapping is bugy.
The JUL log Level OFF shuld be mapped to the Log4j log Level ALL.
In Log4j log level OFF is the highest rank possible, above Fatal, and it is only to be used to qualify categories and never to be used to produce log statements. Someone who uses OFF to log statements does not know what he is doing.
This bug leads to the fact that IRON JAC AMAR - which I am trying to debug, is producing on many layers log statements with level OFF.
I was wondering why I could not filter them out until I realized this.
- 2 - In the cove version you have, you will have double logging of a LogRecord, whenever that log record does not come with any MDC context. I was missing a return statement.
So you will see every log event logged twice.
These bugs however should not matter for this Jira, since the theme here is occasional problematic startup of wildfly.
Many thanks.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (WFCORE-3233) Logging subsystem: Fix SuffixValidator to allow 's' or 'S' symbols in text quoted using single quotes in suffix.
by Ilia Vassilev (JIRA)
Ilia Vassilev created WFCORE-3233:
-------------------------------------
Summary: Logging subsystem: Fix SuffixValidator to allow 's' or 'S' symbols in text quoted using single quotes in suffix.
Key: WFCORE-3233
URL: https://issues.jboss.org/browse/WFCORE-3233
Project: WildFly Core
Issue Type: Bug
Components: Logging
Affects Versions: 4.0.0.Alpha1
Reporter: Ilia Vassilev
Assignee: Ilia Vassilev
Suffix in logging subsystem *-rotating-file-handler cannot include second-of-minute or fraction-of-second symbol. However this symbol is checked even in text quoted using single quotes (') to avoid interpretation. This means that symbols 's' or 'S' cannot be used in text.
See WFCORE-3064 for details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (WFCORE-3231) Logging subsystem: Fix SuffixValidator to allow 's' or 'S' symbols in text quoted using single quotes in suffix.
by Ilia Vassilev (JIRA)
Ilia Vassilev created WFCORE-3231:
-------------------------------------
Summary: Logging subsystem: Fix SuffixValidator to allow 's' or 'S' symbols in text quoted using single quotes in suffix.
Key: WFCORE-3231
URL: https://issues.jboss.org/browse/WFCORE-3231
Project: WildFly Core
Issue Type: Bug
Components: Logging
Affects Versions: 4.0.0.Alpha1
Reporter: Ilia Vassilev
Assignee: Ilia Vassilev
Suffix in logging subsystem *-rotating-file-handler cannot include second-of-minute or fraction-of-second symbol. However this symbol is checked even in text quoted using single quotes (') to avoid interpretation. This means that symbols 's' or 'S' cannot be used in text.
See WFCORE-3064 for details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (WFCORE-3228) WorkerServerDefinition should not be registered on a domain profile
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3228?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3228:
-------------------------------------
Summary: WorkerServerDefinition should not be registered on a domain profile (was: WorkerServerDefinition should not be registered on an HC)
> WorkerServerDefinition should not be registered on a domain profile
> -------------------------------------------------------------------
>
> Key: WFCORE-3228
> URL: https://issues.jboss.org/browse/WFCORE-3228
> Project: WildFly Core
> Issue Type: Bug
> Components: IO
> Affects Versions: 3.0.1.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Title says it all.
> I think removing this isn't an incompatible change because these are runtime-only synthetic resources where WorkerResourceDefinition.WorkerResource will never produce a child resource against which an operation can be targeted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months