[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 7/29/17 6:03 AM:
----------------------------------------------------------------------
Hi Scott, I still have not had the time to dedicate to this task.
I have been prioritizing some other work, since for the time being in relation to this bug, on the instances where the phenomena has taken place, we are doing a "dirty" entitymanager.referesh(myStaleEntity), as work-around. This work-around is useless if one is clueless as to what entity may have been changed in a business transaction, but out of luck, we do know the instances that we are getting served stale.
I hope to be able to dedicate some hours to this next week.
By the way, I must give you guys compliements on the JBOSS CLI.
The CLI is really fast.
We have written python/jython based create domain script for our business configuration (e.g. dynamically produce wildfly CLI based on desired configuration settings - datasources, jms, etc...) and I must say the speed with which a new standalone domain can get created and then finally configured via CLI is incredible. I was not expecting the CLI to be so fast configuring queues, factories, datasources. Incredible. So big compliments!
Kindest regards.
was (Author: nuno.godinhomatos):
Hi Scott, I still have not had the time to dedicate to this task.
I have been prioritizing some other work, since for the time being in relation to this bug, on the instances where the phenomena has taken place, we are doing a "dirty" entitymanager.referesh(myStaleEntity), as work-around. This work-around is useless if one is clueless as to what entity may have been changed in a business transaction, but out of luck, we do know the instances that we are getting served stale. The only problem I have with the current configuration architecture of Wildfly - is that it is not smooth for integration with Eclipse IDE.
Many configuration settings that I may wish to configure (e.g. -X system properties, etc..) I can tune them via dedicated start script for the domains, but there is no change that Eclipse will pick these up because unfortunately eclispe does not allow to tell it to start a domain via custom start script. and such syte properties, they are not effective if you put them in the standalone.xml system properties setting. So that means, manual work opening eclipse launch configuration that add such level of configuration by hand to start a widlfly domain. I think that should surely be improved... Eclipse plugin shuld assume less defaults, and swallow configurations from somewhere under the control of the person that configures the domain, in my oppinion. (I am quite off topic, sorry for that).
I hope to be able to dedicate some hours to this next week.
By the way, I must give you guys compliements on the JBOSS CLI.
The CLI is really fast.
We have written python/jython based create domain script for our business configuration (e.g. dynamically produce wildfly CLI based on desired configuration settings - datasources, jms, etc...) and I must say the speed with which a new standalone domain can get created and then finally configured via CLI is incredible. I was not expecting the CLI to be so fast configuring queues, factories, datasources. Incredible. So big compliments!
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)
7 years, 5 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 edited comment on WFLY-8954 at 7/29/17 6:02 AM:
----------------------------------------------------------------------
Hi Scott, I still have not had the time to dedicate to this task.
I have been prioritizing some other work, since for the time being in relation to this bug, on the instances where the phenomena has taken place, we are doing a "dirty" entitymanager.referesh(myStaleEntity), as work-around. This work-around is useless if one is clueless as to what entity may have been changed in a business transaction, but out of luck, we do know the instances that we are getting served stale. The only problem I have with the current configuration architecture of Wildfly - is that it is not smooth for integration with Eclipse IDE.
Many configuration settings that I may wish to configure (e.g. -X system properties, etc..) I can tune them via dedicated start script for the domains, but there is no change that Eclipse will pick these up because unfortunately eclispe does not allow to tell it to start a domain via custom start script. and such syte properties, they are not effective if you put them in the standalone.xml system properties setting. So that means, manual work opening eclipse launch configuration that add such level of configuration by hand to start a widlfly domain. I think that should surely be improved... Eclipse plugin shuld assume less defaults, and swallow configurations from somewhere under the control of the person that configures the domain, in my oppinion. (I am quite off topic, sorry for that).
I hope to be able to dedicate some hours to this next week.
By the way, I must give you guys compliements on the JBOSS CLI.
The CLI is really fast.
We have written python/jython based create domain script for our business configuration (e.g. dynamically produce wildfly CLI based on desired configuration settings - datasources, jms, etc...) and I must say the speed with which a new standalone domain can get created and then finally configured via CLI is incredible. I was not expecting the CLI to be so fast configuring queues, factories, datasources. Incredible. So big compliments!
Kindest regards.
was (Author: nuno.godinhomatos):
Hi Scott, I still have not had the time to dedicate to this task.
I have been prioritizing some other work, since for the time being in relation to this bug, on the instances where the phenomena has taken place, we are doing a "dirty" entitymanager.referesh(myStaleEntity), as work-around. This work-around is useless if one is clueless as to what entity may have been changed in a business transaction, but out of luck, we do know the instances that we are getting served stale.
I hope to be able to dedicate some hours to this next week.
By the way, I must give you guys compliements on the JBOSS CLI.
The CLI is really fast.
We have written python/jython based create domain script for our business configuration (e.g. dynamically produce wildfly CLI based on desired configuration settings - datasources, jms, etc...) and I must say the speed with which a new standalone domain can get created and then finally configured via CLI is incredible. I was not expecting the CLI to be so fast configuring queues, factories, datasources. Incredible. So big compliments!
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)
7 years, 5 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 Scott, I still have not had the time to dedicate to this task.
I have been prioritizing some other work, since for the time being in relation to this bug, on the instances where the phenomena has taken place, we are doing a "dirty" entitymanager.referesh(myStaleEntity), as work-around. This work-around is useless if one is clueless as to what entity may have been changed in a business transaction, but out of luck, we do know the instances that we are getting served stale.
I hope to be able to dedicate some hours to this next week.
By the way, I must give you guys compliements on the JBOSS CLI.
The CLI is really fast.
We have written python/jython based create domain script for our business configuration (e.g. dynamically produce wildfly CLI based on desired configuration settings - datasources, jms, etc...) and I must say the speed with which a new standalone domain can get created and then finally configured via CLI is incredible. I was not expecting the CLI to be so fast configuring queues, factories, datasources. Incredible. So big compliments!
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)
7 years, 5 months
[JBoss JIRA] (WFCORE-3073) Handle TERM gracefully
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3073:
------------------------------------------
[~swd847] FYI.
> Handle TERM gracefully
> ----------------------
>
> Key: WFCORE-3073
> URL: https://issues.jboss.org/browse/WFCORE-3073
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Parees
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha1
>
>
> The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFCORE-3073) Handle TERM gracefully
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3073:
------------------------------------------
Requirement analysis doc for this feature: https://developer.jboss.org/docs/DOC-56032
Possible implementation is at https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO..., although that needs an integration test. Manual use shows the suspend logic gets invoked as expected.
> Handle TERM gracefully
> ----------------------
>
> Key: WFCORE-3073
> URL: https://issues.jboss.org/browse/WFCORE-3073
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Parees
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha1
>
>
> The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (DROOLS-1683) ExcelParse can re-write files
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1683?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1683:
--------------------------------
Sprint: 2017 Week 30-31
> ExcelParse can re-write files
> -----------------------------
>
> Key: DROOLS-1683
> URL: https://issues.jboss.org/browse/DROOLS-1683
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.0.0.Final
> Reporter: James Livingston
> Assignee: Mario Fusco
>
> ExcelParser.open(File) uses the single argument WorkbookFactory.create() call, which opens the file in read-write mode, so when parseWorkbook() calls close on it, it will save the workbook to disk.
> Usually the resulting file is the same, however it may be binary-different but equivalent(causing git conflicts). Being read-only does not cause an error since the exceptions are swallowed silently.
> It should use the three argument form of WorkbookFactory.create() and pass the read-only flag
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFLY-8456) Protocols added to a fork of some channel won't show in JMX MBeans
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8456?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-8456:
------------------------------------
I would suggest moving the mbean registration logic from ChannelBuilder to the ChannelFactory implementations themselves. This eliminates the need for special handling for externally created channels. Something like:
{code:java}
public MyChannelFactory implements ChannelFactoy, ChannelListener {
@Override
public Channel createChannel(String id) {
Channel channel = // create channel
JmxConfigurator.registerChannel(channel, ...);
channel.addListener(this);
return channel;
}
@Override
public void channelClosed(Channel channel) {
JmxConfigurator.unregisterChannel(channel, ...);
channel.removeListener(this);
}
}
{code}
> Protocols added to a fork of some channel won't show in JMX MBeans
> ------------------------------------------------------------------
>
> Key: WFLY-8456
> URL: https://issues.jboss.org/browse/WFLY-8456
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Optional
>
> When defining a fork of some channel and adding a protocol to the protocol stack of that fork channel, the newly added protocol won't show up in JMX MBeans.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months