[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
[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
[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
[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
[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
[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
[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
[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
[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