[JBoss JIRA] (WFLY-9239) [GSS](7.1.0) Timer fails if transaction isolation set to SERIALIZABLE
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9239?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-12775 to WFLY-9239:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9239 (was: JBEAP-12775)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
(was: EJB)
Affects Version/s: (was: 7.0.0.GA)
(was: 7.0.1.GA)
(was: 7.0.2.GA)
(was: 7.0.3.GA)
> [GSS](7.1.0) Timer fails if transaction isolation set to SERIALIZABLE
> ---------------------------------------------------------------------
>
> Key: WFLY-9239
> URL: https://issues.jboss.org/browse/WFLY-9239
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: Linux, JDK8, Timer Database persistence
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: downstream_dependency
>
> If the transaction isolation level is set to SERIALIZABLE if one node aquires the row lock via the
> UPDATE JBOSS_EJB_TIMER..
> the other nodes throw an
> ORA-08177: can't serialize access for this transaction
> exception.
> The timer thats row threw the exception never runs any more, not even in case the other nodes were shut down.
> The serialization exception is also thrown upon server/application startup sometimes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2211) UUID not serializable
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2211?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2211:
--------------------------------
OK, can you close the issue then?
> UUID not serializable
> ---------------------
>
> Key: JGRP-2211
> URL: https://issues.jboss.org/browse/JGRP-2211
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.5
> Reporter: Chris LastName
> Assignee: Bela Ban
> Priority: Minor
>
> Caused by: java.lang.RuntimeException: java.io.NotSerializableException: org.jgroups.util.UUID
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:574)
> at org.jgroups.JChannel.up(JChannel.java:797)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:891)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.getStateFromApplication(STATE_TRANSFER.java:328)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleStateReq(STATE_TRANSFER.java:313)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.handle(STATE_TRANSFER.java:284)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.handle(STATE_TRANSFER.java:31)
> at org.jgroups.util.ProcessingQueue.process(ProcessingQueue.java:54)
> at org.jgroups.util.ProcessingQueue.add(ProcessingQueue.java:35)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:132)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:177)
> ...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3192) Remarshaling the default configuration xml files shouldn't change the files
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3192?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3192:
-------------------------------------
Issue Type: Bug (was: Enhancement)
> Remarshaling the default configuration xml files shouldn't change the files
> ---------------------------------------------------------------------------
>
> Key: WFCORE-3192
> URL: https://issues.jboss.org/browse/WFCORE-3192
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta31
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> Starting a server and provoking a marshaling of the model without any real change on the default configuration files shouldn't result in a different files (with empty lines).
> Reproducer:
> * start the server or domain
> * add and remove a system property using the CLI
> * diff the resulting configuration file with the initial one.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9236) Remarshaling the default configuration xml files shouldn't change the files
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9236?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9236:
-----------------------------------
Issue Type: Bug (was: Enhancement)
> Remarshaling the default configuration xml files shouldn't change the files
> ---------------------------------------------------------------------------
>
> Key: WFLY-9236
> URL: https://issues.jboss.org/browse/WFLY-9236
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 11.0.0.Beta1
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> Starting a server and provoking a marshaling of the model without any real change on the default configuration files shouldn't result in a different files (with empty lines).
> Reproducer:
> * start the server or domain
> * add and remove a system property using the CLI
> * diff the resulting configuration file with the initial one.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2441) Inconsistency between DMR and XSD representation of Elytron simple-permission-mapper
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2441?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2441:
------------------------------------------
Making a nillable attribute non-nillable is a breaking API change so it shouldn't be done for less than critical reasons. Note that I'm talking about truly nillable here, i.e. the attribute can be left undefined and you still get a properly functioning system. If there is wrong metadata that says it can be undefined but it blows up if you try, fixing the metadata is not a breaking change.
> Inconsistency between DMR and XSD representation of Elytron simple-permission-mapper
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-2441
> URL: https://issues.jboss.org/browse/WFCORE-2441
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta7
> Reporter: Ondrej Kotek
> Assignee: Ilia Vassilev
> Labels: user_experience
>
> There are inconsistencies between DMR and XSD representation of {{constant-permission-mapper}}.
> According to XSD {{permission}} must occur at least one times in {{constant-permission-mapper}}. According to DMR it is {{"nillable" => true}}. This should be unified.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 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:
---------------------------------------------
Ok thanks for all the info. I will do as you said with using the master as the base for the branch with this test. As for going forward with the fix I must admit I am curious to play with this layer of code so I will experiment with it and let you know if am clueless or make any relevant progress. But most likely I will not really be able to do this during normal working days due to sone important tasks that take presence, although it's a fact that this bug is having an impact and we have so called dirty business logic because of it. And this must really go away... Ok i will report back to you soon. 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, 9 months