January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2232: --------------------------- Description: According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us. Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!). Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age): 967 elements: {noformat} i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old) i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old) i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old) i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old) i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old) i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old) i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old) i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old) i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old) i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old) i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old) i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old) ... {noformat} was: According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us. Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!). Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age): 967 elements: i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old) i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old) i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old) i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old) i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old) i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old) i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old) i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old) i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old) i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old) i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old) i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old) ... > Using NATIVE_S3_PING old members doesn't seem to get removed > ------------------------------------------------------------ > > Key: JGRP-2232 > URL: https://issues.jboss.org/browse/JGRP-2232 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.7 > Environment: Spring Boot / Boxfuse / AWS > Reporter: Jesper Blomquist > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.10 > > > According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us. > Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!). > Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age): > 967 elements: > {noformat} > i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old) > i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old) > i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old) > i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old) > i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old) > i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old) > i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old) > i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old) > i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old) > i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old) > i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old) > i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old) > ... > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2270) [DMN Editor] Replace "Return to DRG" button with Link

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2270?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2270: ----------------------------------- Tester: Jozef Marko > [DMN Editor] Replace "Return to DRG" button with Link > ----------------------------------------------------- > > Key: DROOLS-2270 > URL: https://issues.jboss.org/browse/DROOLS-2270 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Affects Versions: 7.5.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > > The "Return to DRG" button should be replaced with a "<< Back to XXX" link. > XXX should be the name of the DRG from whence the User came. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2270) [DMN Editor] Replace "Return to DRG" button with Link

by Michael Anstis (JIRA)

Michael Anstis created DROOLS-2270: -------------------------------------- Summary: [DMN Editor] Replace "Return to DRG" button with Link Key: DROOLS-2270 URL: https://issues.jboss.org/browse/DROOLS-2270 Project: Drools Issue Type: Feature Request Components: DMN Editor Affects Versions: 7.5.0.Final Reporter: Michael Anstis Assignee: Michael Anstis The "Return to DRG" button should be replaced with a "<< Back to XXX" link. XXX should be the name of the DRG from whence the User came. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2247) RPC does not invoke interface's default methods inherited

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2247?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2247: -------------------------------- No problem! I'm known to be fast! :-) > RPC does not invoke interface's default methods inherited > --------------------------------------------------------- > > Key: JGRP-2247 > URL: https://issues.jboss.org/browse/JGRP-2247 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 4.0.8 > Environment: jgroups 4.0.8.Final > java version "1.8.0_151" > Java(TM) SE Runtime Environment (build 1.8.0_151-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode) > on win 10 > Reporter: rokk ebol > Assignee: Bela Ban > Fix For: 4.0.10 > > > org.jgroups.blocks.MethodCall#getAllMethods looks for methods up there in superclasses but not in interfaces, which can contain default methods since java 8 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2247) RPC does not invoke interface's default methods inherited

by rokk ebol (JIRA)

[ https://issues.jboss.org/browse/JGRP-2247?page=com.atlassian.jira.plugin.... ] rokk ebol commented on JGRP-2247: --------------------------------- Great! Thanks Didn't expect this to be done so fast > RPC does not invoke interface's default methods inherited > --------------------------------------------------------- > > Key: JGRP-2247 > URL: https://issues.jboss.org/browse/JGRP-2247 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 4.0.8 > Environment: jgroups 4.0.8.Final > java version "1.8.0_151" > Java(TM) SE Runtime Environment (build 1.8.0_151-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode) > on win 10 > Reporter: rokk ebol > Assignee: Bela Ban > Fix For: 4.0.10 > > > org.jgroups.blocks.MethodCall#getAllMethods looks for methods up there in superclasses but not in interfaces, which can contain default methods since java 8 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2246) Internal thread pool not created if default thread pool is injected

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2246 at 1/24/18 6:36 AM: --------------------------------------------------------- I added method {{setInternalThreadPool()}} in JGRP-2244. I assume this resolved your issue? And, no, I don't want to create the internal thread pool is {{thread_pool_enabled}} is {{false}}, as this attribute governs the creation of both pools. was (Author: belaban): I added method {{setInternalThreadPool()}} in JGRP-2244. I assume this resolved your issue? > Internal thread pool not created if default thread pool is injected > ------------------------------------------------------------------- > > Key: JGRP-2246 > URL: https://issues.jboss.org/browse/JGRP-2246 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.9 > Reporter: Paul Ferraro > Assignee: Bela Ban > Fix For: 4.0.10 > > > WildFly injects a custom thread pool into its JGroups transports. > However, in JGroups 4.0.x, only the default thread pool exposes a {{setThreadPool(...)}} method. The internal thread pool does not. However, the logic within {{TP.init()}} will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly. > Can we restore the {{TP.setInternalThreadPool(...)}} method? Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when {{thread_pool_enabled}} is true? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2246) Internal thread pool not created if default thread pool is injected

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2246. ---------------------------- Resolution: Duplicate Issue Please re-open if needed! > Internal thread pool not created if default thread pool is injected > ------------------------------------------------------------------- > > Key: JGRP-2246 > URL: https://issues.jboss.org/browse/JGRP-2246 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.9 > Reporter: Paul Ferraro > Assignee: Bela Ban > Fix For: 4.0.10 > > > WildFly injects a custom thread pool into its JGroups transports. > However, in JGroups 4.0.x, only the default thread pool exposes a {{setThreadPool(...)}} method. The internal thread pool does not. However, the logic within {{TP.init()}} will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly. > Can we restore the {{TP.setInternalThreadPool(...)}} method? Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when {{thread_pool_enabled}} is true? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2246) Internal thread pool not created if default thread pool is injected

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2246: -------------------------------- I added method {{setInternalThreadPool()}} in JGRP-2244. I assume this resolved your issue? > Internal thread pool not created if default thread pool is injected > ------------------------------------------------------------------- > > Key: JGRP-2246 > URL: https://issues.jboss.org/browse/JGRP-2246 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.9 > Reporter: Paul Ferraro > Assignee: Bela Ban > Fix For: 4.0.10 > > > WildFly injects a custom thread pool into its JGroups transports. > However, in JGroups 4.0.x, only the default thread pool exposes a {{setThreadPool(...)}} method. The internal thread pool does not. However, the logic within {{TP.init()}} will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly. > Can we restore the {{TP.setInternalThreadPool(...)}} method? Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when {{thread_pool_enabled}} is true? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2246) Internal thread pool not created if default thread pool is injected

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2246: --------------------------- Description: WildFly injects a custom thread pool into its JGroups transports. However, in JGroups 4.0.x, only the default thread pool exposes a {{setThreadPool(...)}} method. The internal thread pool does not. However, the logic within {{TP.init()}} will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly. Can we restore the {{TP.setInternalThreadPool(...)}} method? Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when {{thread_pool_enabled}} is true? was: WildFly injects a custom thread pool into its JGroups transports. However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method. The internal thread pool does not. However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly. Can we restore the TP.setInternalThreadPool(...) method? Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when thread_pool_enabled is true? > Internal thread pool not created if default thread pool is injected > ------------------------------------------------------------------- > > Key: JGRP-2246 > URL: https://issues.jboss.org/browse/JGRP-2246 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.9 > Reporter: Paul Ferraro > Assignee: Bela Ban > Fix For: 4.0.10 > > > WildFly injects a custom thread pool into its JGroups transports. > However, in JGroups 4.0.x, only the default thread pool exposes a {{setThreadPool(...)}} method. The internal thread pool does not. However, the logic within {{TP.init()}} will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly. > Can we restore the {{TP.setInternalThreadPool(...)}} method? Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when {{thread_pool_enabled}} is true? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2269) Retrieve all rules associated to a ruleflow-group

by Richard Bourner (JIRA)

Richard Bourner created DROOLS-2269: --------------------------------------- Summary: Retrieve all rules associated to a ruleflow-group Key: DROOLS-2269 URL: https://issues.jboss.org/browse/DROOLS-2269 Project: Drools Issue Type: Enhancement Reporter: Richard Bourner Assignee: Edson Tirelli Priority: Minor It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask. Maybe another way to do it would be via a search using metadata (such as ruleflow-group). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 January 2018