February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks

by William Burns (JIRA)

[ https://issues.jboss.org/browse/JGRP-1908?page=com.atlassian.jira.plugin.... ] William Burns commented on JGRP-1908: ------------------------------------- [~belaban] if there is no response when you release the build, I would say just to close this out. > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-4394) Make use of TCCL in ARQ ManagedContainer configurable

by Thomas Diesler (JIRA)

Thomas Diesler created WFLY-4394: ------------------------------------ Summary: Make use of TCCL in ARQ ManagedContainer configurable Key: WFLY-4394 URL: https://issues.jboss.org/browse/WFLY-4394 Project: WildFly Issue Type: Feature Request Components: Test Suite Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 9.0.0.Beta1 In WildFly it is considerred intended behaviour that test code gets called with the TCCL set to the test deployment. IMHO this shadows potential problems when the functionality under test is not called from an ARQ test case (i.e. from an normal javaee endpoint) For Camel integration this behaviour is not acceptable. CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/340 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4393) Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers

by Takashi Nishigaya (JIRA)

[ https://issues.jboss.org/browse/WFLY-4393?page=com.atlassian.jira.plugin.... ] Takashi Nishigaya updated WFLY-4393: ------------------------------------ Affects Version/s: 8.2.0.Final > Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers > ------------------------------------------------------------------------------------------ > > Key: WFLY-4393 > URL: https://issues.jboss.org/browse/WFLY-4393 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Reporter: Takashi Nishigaya > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4393) Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers

by Takashi Nishigaya (JIRA)

[ https://issues.jboss.org/browse/WFLY-4393?page=com.atlassian.jira.plugin.... ] Takashi Nishigaya updated WFLY-4393: ------------------------------------ Component/s: Web Services > Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers > ------------------------------------------------------------------------------------------ > > Key: WFLY-4393 > URL: https://issues.jboss.org/browse/WFLY-4393 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.2.0.Final > Reporter: Takashi Nishigaya > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4393) Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers

by Takashi Nishigaya (JIRA)

Takashi Nishigaya created WFLY-4393: --------------------------------------- Summary: Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers Key: WFLY-4393 URL: https://issues.jboss.org/browse/WFLY-4393 Project: WildFly Issue Type: Bug Reporter: Takashi Nishigaya Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1917) FILE_PING: options to remove zombies

by Bela Ban (JIRA)

Bela Ban created JGRP-1917: ------------------------------ Summary: FILE_PING: options to remove zombies Key: JGRP-1917 URL: https://issues.jboss.org/browse/JGRP-1917 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.3 In {{FILE_PING}} and subclasses ({{S3_PING}}, {{GOOGLE_PING}}), coordinators write the files (e.g. {{A.list}} for coord {{A}}). There's a shutdown hook that removes {{A.list}} when {{A}} crashes. However, when a coordinator is killed by kill -9, the file {{A.list}} won't get removed. The problem with this is that new members will read {{A.list}} and get delayed trying to ask {{A}} to join the cluster although {{A}}'s not alive anymore ({{B}} is and created {{B.list}}). Possible solution: implement a mechanism similar to JGRP-1915 where a coordinator removes *all files* on a view change with leaving members, and then writes its file again. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1245) Custom URL selector doesn't take effect

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1245?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1245: ------------------------------------------------ Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1182879|https://bugzilla.redhat.com/show_bug.cgi?id=1182879] from ON_QA to VERIFIED > Custom URL selector doesn't take effect > --------------------------------------- > > Key: JBJCA-1245 > URL: https://issues.jboss.org/browse/JBJCA-1245 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.0.30.Final, 1.1.9.Final, 1.2.2.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.31.Final, 1.1.10.Final, 1.2.3.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-544) Inconsistent handling of system properties.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-544?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-544: ------------------------------------------------ Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1192467|https://bugzilla.redhat.com/show_bug.cgi?id=1192467] from ON_QA to VERIFIED > Inconsistent handling of system properties. > -------------------------------------------- > > Key: WFCORE-544 > URL: https://issues.jboss.org/browse/WFCORE-544 > Project: WildFly Core > Issue Type: Bug > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Fix For: 1.0.0.Alpha19 > > > Description of problem: > Having a domain with a single server group and two eap hosts (all on localhost), following system property cause server to fail on startup: > <property name="org.jbpm.designer.perspective" value="${org.jbpm.designer.perspective:full}"/> > The problem occurs only in definition with possibility to override default value - <property name="X" value="${Y:default}"/>, where X = Y > Please see the error message in attached server log excerpt. > More interesting is the fact that the issue shows with domain mode only, standalone mode works with properties defined as above. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4356) build.sh fails on OS X

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-4356?page=com.atlassian.jira.plugin.... ] Carlo de Wolf reassigned WFLY-4356: ----------------------------------- Assignee: Carlo de Wolf (was: Paul Gier) > build.sh fails on OS X > ----------------------- > > Key: WFLY-4356 > URL: https://issues.jboss.org/browse/WFLY-4356 > Project: WildFly > Issue Type: Bug > Components: Build System > Reporter: Jeff Mesnil > Assignee: Carlo de Wolf > > the build.sh script fails on Mac OS X: > {noformat} > $ ./build.sh clean install > Maven already exists > Maven is correct version > ./build.sh: line 107: ulimit: open files: cannot modify limit: Invalid argument > {noformat} > The ulimit error was already present before but since WFLY-4305, the build.sh script will exit after this error instead of continuing. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-567) Invoking shutdown command for slave HC results in CLI disconnecting

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-567?page=com.atlassian.jira.plugin... ] Alexey Loubyansky commented on WFCORE-567: ------------------------------------------ This was supposed to be fixed before. https://github.com/aloubyansky/wildfly-core/commit/a2d3bc62188df66e61f42a... introduced boolean isMaster(ModelControllerClient client, String host) method for that. > Invoking shutdown command for slave HC results in CLI disconnecting > ------------------------------------------------------------------- > > Key: WFCORE-567 > URL: https://issues.jboss.org/browse/WFCORE-567 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha19 > Reporter: Brian Stansberry > Assignee: Alexey Loubyansky > > Connect the CLI to the master in a domain with a slave HC and shut down the slave. CLI disconnects: > {code} > [domain@localhost:9990 /] shutdown --host=slave > [disconnected /] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2015