[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1908?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1908.
----------------------------
Resolution: Won't Fix
Please reopen if this is still an issue
> Optional Executing protocol behavior to not attempt to repeat tasks
> -------------------------------------------------------------------
>
> Key: JGRP-1908
> URL: https://issues.jboss.org/browse/JGRP-1908
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Anuj Shah
> Assignee: William Burns
> Labels: executionservice
> Fix For: 3.6.3
>
>
> As discussed on forum:
> http://jgroups.1086181.n5.nabble.com/jgroups-users-ExecutionService-at-le...
> {quote}
> I've noticed that runnable tasks submitted to the ExecutionService can be run more than once!
> This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc
> // The person currently servicing our request has gone down
> // without completing so we have to keep our request alive by
> // sending ours back to the coordinator
> The problem is that there is no guarantee that the request was not completed.
> For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout.
> I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though)
> Perhaps there could be control over the behaviour:
> * At least once - assumes task failed and resubmits
> * At most once - assumes task completed and cleans up - may not actually be complete
> * Exactly once - not sure if this is possible
> {quote}
> There is a simple change to exhibit the at least once behaviour by ignoring consumers that have left. I have the patch in my fork:
> https://github.com/anujshahwork/JGroups/commit/0f2c1f6f9ed57744841acdd192...
> Which my project is using. This can be wrapped in some simple configuration on the protocol to control the behaviour and would be a useful addition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JGRP-1918) ConcurrentModificationException in Locking notification
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1918?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1918.
----------------------------
Resolution: Done
Using a copy-on-write set for lock listeners
> ConcurrentModificationException in Locking notification
> -------------------------------------------------------
>
> Key: JGRP-1918
> URL: https://issues.jboss.org/browse/JGRP-1918
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.2
> Environment: JUnit text running in Eclipse on Windows
> Reporter: Paul Illingworth
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> I have code which unregisters a lock listener whilst a lock notification event is being fired leading to
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926)
> at java.util.HashMap$KeyIterator.next(HashMap.java:960)
> at org.jgroups.protocols.Locking.notifyUnlocked(Locking.java:581)
> at org.jgroups.protocols.Locking$ServerLock.setOwner(Locking.java:767)
> at org.jgroups.protocols.Locking$ServerLock.handleRequest(Locking.java:655)
> at org.jgroups.protocols.Locking.handleLockRequest(Locking.java:393)
> at org.jgroups.protocols.Locking.up(Locking.java:226)
> at org.jgroups.stack.Protocol.up(Protocol.java:412)
> at org.jgroups.protocols.FORK.up(FORK.java:139)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.stack.Protocol.up(Protocol.java:420)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.deliverBatch(UNICAST3.java:1087)
> at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:886)
> at org.jgroups.protocols.UNICAST3.handleDataReceivedFromSelf(UNICAST3.java:821)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:424)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:253)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
> at org.jgroups.protocols.Discovery.up(Discovery.java:291)
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2842)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
> at org.jgroups.protocols.TP$3.run(TP.java:1511)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> The org.jgroups.protocols.Locking#lock_listeners is simple a HashSet which gets iterated over, This needs to be synchronised is some way.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4390) restartable=false bach job can be restarted
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4390?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya commented on WFLY-4390:
-----------------------------------------
Thank you, Cheng.
I verified your fixed against WildFly 9 works well!
> restartable=false bach job can be restarted
> -------------------------------------------
>
> Key: WFLY-4390
> URL: https://issues.jboss.org/browse/WFLY-4390
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Cheng Fang
> Attachments: batch-restartable.zip
>
>
> The batch job defined with restartable=false must not be restartable, after failed or stopped.
> GlassFish 4.1 results in the following:
> [2015-02-26T19:56:34.860+0900] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=25 _ThreadName=Thread-9] [timeMillis: 1424948194860] [levelValue: 1000] [[
> javax.batch.operations.JobRestartException: javax.batch.operations.JobRestartException: Job Restartable attribute is false, Job cannot be restarted.
> But WildFly tries to execute the stopped or failed job.
> Please check the attached test case.
> wildfly:
> $ mvn clean test -P wildfly-managed (or -P wildly-remote)
> glassfish:
> $ glassfish4/bin/asadmin start-domain
> $ mvn clean test -P glassfish-remote
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4335) ArquillianService incorrectly sets TCCL
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4335?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4335:
--------------------------------------
It is true because the spec requires it, and we make sure we set the correct TCCL at each entry point.
> ArquillianService incorrectly sets TCCL
> ---------------------------------------
>
> Key: WFLY-4335
> URL: https://issues.jboss.org/browse/WFLY-4335
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.2.0.Final
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
>
> While integrating Camel in WildFly I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
> Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
> This shadows potential problems when TCCL is not set or set to something else.
> Related: https://github.com/wildfly-extras/wildfly-camel/issues/292
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (DROOLS-732) Extract objects from handles in a type-safe way
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-732:
-------------------------------------
Summary: Extract objects from handles in a type-safe way
Key: DROOLS-732
URL: https://issues.jboss.org/browse/DROOLS-732
Project: Drools
Issue Type: Enhancement
Reporter: Davide Sottara
Assignee: Davide Sottara
Priority: Minor
The (Internal)FactHandle interface exposes a generic method
{code} public Object getObject() {code}
It should expose another method that wraps an internal cast
{code} public <K> K as( Class<K> klass ) throws CCE {code}
The method will perform the necessary type checks.
The method will also work with traits, returning a proxy that
implements the appropriate interface
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JGRP-1915) JDBC_PING discovery fails when stale entries are found in the database
by Patrick Haas (JIRA)
[ https://issues.jboss.org/browse/JGRP-1915?page=com.atlassian.jira.plugin.... ]
Patrick Haas commented on JGRP-1915:
------------------------------------
A note on the sorting/shuffling:
The coordinators are shuffled, but if there are no coordinators, the remaining members are sorted:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
I'll take a look at your other feedback now. Thanks :)
> JDBC_PING discovery fails when stale entries are found in the database
> ----------------------------------------------------------------------
>
> Key: JGRP-1915
> URL: https://issues.jboss.org/browse/JGRP-1915
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Reporter: Patrick Haas
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> Node: "CHQ-PATRICKH-55008"
> Database contains two rows.. other node is dead but was unable to remove the JDBC entry.
> 1) JChannel.connect(...)
> 2) JChannel.down(Event[CONNECT_WITH_STATE_TRANSFER_USE_FLUSH])
> 3) STATE_TRANSFER -> FRAG2 -> MFC -> UFC -> GMS
> 4) GMS.down(...) calls out to joinWithStateTransfer -> joinInternal(...)
> JDBC pulls the node list from the database table.
> Ping Data:
> - CHQ-PATRICKH-3895, name=CHQ-PATRICKH-3895, addr=10.1.130.228:55503, server
> - CHQ-PATRICKH-55008, name=CHQ-PATRICKH-55008, addr=10.1.130.228:57489
> joinInternal is a never-terminating while loop:
> - down: Event.FIND_INITIAL_MBRS_EVT
> - inspect responses -- no valid join responses
> - responses are NOT empty -> does not become singletonMember
> - gets all coordinators (none)
> - Sorts all nodes by GUID in a TreeSet
> - Is first of all joiners?
> - No, another joiner is listed first
> ... repeat forever
> When the process is restarted and a node ID < than the existing db entry is generated, it successfully takes over as owner.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months