[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 edited comment on JGRP-2232 at 1/24/18 7:53 AM:
---------------------------------------------------------
Try reducing {{logical_addr_cache_max_size}} (default: 2000). E.g. set it to 10 or 20.
was (Author: belaban):
Try reducing {{logical_addr_cache_max_size}} (default: 2000). E.g. set it to 10 0r 20.
> 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] (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 commented on JGRP-2232:
--------------------------------
OK, I can reproduce this even with {{FILE_PING}}, working on it...
> 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] (WFCORE-3075) KeyStore password as default KeyManager password
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3075?page=com.atlassian.jira.plugi... ]
Jan Kalina updated WFCORE-3075:
-------------------------------
Issue Type: Enhancement (was: Bug)
> KeyStore password as default KeyManager password
> ------------------------------------------------
>
> Key: WFCORE-3075
> URL: https://issues.jboss.org/browse/WFCORE-3075
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Jan Kalina
> Priority: Critical
> Labels: keymanager, keystore, trustmanager
>
> In Elytron, there is keystore password (key-store resource) and key password (key-managers resource) required.
> However in theory there could be cases, where no password can be intended
> - key-store resource for truststore purposes (reading truststore) (but in legacy is password required)
> - PKCS12 can be created without key password (but keystore password in legacy is required)
> - you can create JKS programatically without keystore password
> - *in legacy key password is optional (which mean keystore password is used)*
> From discussion: We can make the password optional on the KeyManager so if no password is specified on the KeyManager we assume it is the one from the KeyStore.
> Created analysis document for this: https://developer.jboss.org/wiki/AnalysisDesign-KeyStorePasswordAsDefault...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[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 edited comment on JGRP-2232 at 1/24/18 7:29 AM:
---------------------------------------------------------
Try reducing {{logical_addr_cache_max_size}} (default: 2000). E.g. set it to 10 0r 20.
was (Author: belaban):
Try reducing {{logical_addr_cache_max_size}} (default: 2000).
> 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