[JBoss JIRA] (WFLY-7304) Compensations subsystem
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-7304:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> Compensations subsystem
> -----------------------
>
> Key: WFLY-7304
> URL: https://issues.jboss.org/browse/WFLY-7304
> Project: WildFly
> Issue Type: Task
> Components: Transactions
> Reporter: Gytis Trikleris
> Assignee: Ondra Chaloupka
> Priority: Minor
> Fix For: 12.0.0.Final
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-9261) Cluster connection receives a "consumer created" message from the rebooting node but it has no corresponding binding for it locally
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9261?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9261:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> Cluster connection receives a "consumer created" message from the rebooting node but it has no corresponding binding for it locally
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9261
> URL: https://issues.jboss.org/browse/WFLY-9261
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Flavia Rainone
> Assignee: Martyn Taylor
> Fix For: 12.0.0.Final
>
>
> When rebooting a cluster node that uses singleton cluster mdbs, we get this error message:
> {noformat}
> 2017-07-25 16:08:54,426 ERROR [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.HelloWorldMDBQueuedea3e995-713c-11e7-85f2-b8f6b112daf7 on ClusterConnectionImpl@1129705701[nodeUUID=dabaa1fa-713c-11e7-8f3a-b8f6b112daf7, connector=TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=http-acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=9080&host=localhost, address=jms, server=ActiveMQServerImpl::serverUUID=dabaa1fa-713c-11e7-8f3a-b8f6b112daf7]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-8954:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> 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
> Fix For: 12.0.0.Final
>
>
> 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.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-8467) simple-election-policy is not sufficiently descriptive
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-8467?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-8467:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> simple-election-policy is not sufficiently descriptive
> ------------------------------------------------------
>
> Key: WFLY-8467
> URL: https://issues.jboss.org/browse/WFLY-8467
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 12.0.0.Final
>
>
> simple-election-policy was originally a port of http://anonsvn.jboss.org/repos/jbossas/trunk/cluster/src/main/java/org/jb...
> It's time to revisit this.
> 1. The term "simple" doesn't at all describe how the policy elects the primary node.
> 2. "position" isn't intuitive either - until you realize that it is a reference to the underlying data structure.
> 3. Is the ability to specify the nth youngest or oldest node a realistic requirement?
> We can generalize this policy as doing 2 things:
> a. Sorts the candidates based on some criteria (e.g. age, name)
> b. Select the head of the sorted list
> This is logically equivalent to:
> members.stream().sort(comparator).findFirst();
> Proposal:
> <age-election-policy sort="DESCENDING|ASCENDING"/>
> <name-election-policy sort="ASCENDING|DESCENDING"/>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-9344) Let Infinispan manage eviction for distributed web sessions and @Stateful EJBs
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9344?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9344:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> Let Infinispan manage eviction for distributed web sessions and @Stateful EJBs
> ------------------------------------------------------------------------------
>
> Key: WFLY-9344
> URL: https://issues.jboss.org/browse/WFLY-9344
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 12.0.0.Final
>
>
> With Infinispan's transition to Caffeine to implement its data container, WF should finally be able to offload eviction to Infinispan, by configuring caffeine to use a specific Weigher that returns 0 for non-primary session entries, where max-active-sessions is configured as the maximumWeight. From an Infinispan configuration perspective, this corresponds to a custom EntrySizeCalculator that returns 0 for non-primary session entries, and a maxSize equal to the max-active-sessions. The remaining entries would rely on cascading eviction (i.e. manually evicting from a via passivation callback).
> As of Infinispan 9.1, the requisite DataContainer configuration attributes are deprecated - thus we need to lobby to expose the mechanisms for overriding the entry size calculator to be able to ensure this solution will be supported in the future.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months