[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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 months
[JBoss JIRA] (LOGMGR-161) AsyncHandler is always creating a stacktrace dump
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-161?page=com.atlassian.jira.plugin... ]
James Perkins reassigned LOGMGR-161:
------------------------------------
Assignee: James Perkins
> AsyncHandler is always creating a stacktrace dump
> -------------------------------------------------
>
> Key: LOGMGR-161
> URL: https://issues.jboss.org/browse/LOGMGR-161
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Components: core
> Affects Versions: 2.1.0.Alpha1
> Reporter: Koen Janssens
> Assignee: James Perkins
>
> I have noticed that when introducing an AsyncHandler for logging, all log statement are copied before being put on the queue and as part of that copy a complete stack dump is done.
> This might be useful if the stack info is used by a downstream formatter (eg for line number identification), but even if the line numbers are not used anywhere, this still happens.
> I think this behavior should be at least optional.
> Source Location: org.jboss.logmanager.ExtLogRecord#copyAll
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 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 updated WFCORE-3073:
-------------------------------------
Summary: Handle TERM gracefully (was: Handle TERM cleanly)
> 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)
8 years, 6 months
[JBoss JIRA] (WFCORE-3124) Handle TERM gracefully
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3124:
----------------------------------------
Summary: Handle TERM gracefully
Key: WFCORE-3124
URL: https://issues.jboss.org/browse/WFCORE-3124
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)
8 years, 6 months