September 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove failed members

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1956?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1956 at 9/2/15 2:44 AM: -------------------------------------------------------- Can you try with the following attributes enabled: ? * {{remove_old_coords_on_view_change}} * {{remove_all_files_on_view_change}} The reason old members are not immediately removed is that these members could have been split away, in a network partition, rather than crashed. If we want a merge to succeed in such a case, it is better to leave information about them in the store. Note that {{TP.logical_addr_cache_max_size}} and {{TP.logical_addr_cache_expiration}} govern when stale entries will be removed. By default, you won't have more than 2000 stale elements in the cache. Take a look at https://issues.jboss.org/browse/JGRP-1917 for details was (Author: belaban): Can you try with the following attributes enabled: ? * {{remove_old_coords_on_view_change}} * {{remove_all_files_on_view_change}} The reason old members are not immediately removed is that these members could have been split away, in a network partition, rather than crashed. If we want a merge to succeed in such a case, it is better to leave information about them in the store. Note that {{TP.logical_addr_cache_max_size}} and {{TP.logical_addr_cache_expiration}} govern when stale entries will be removed. By default, you won't have more than 2000 stale elements in the cache. > S3_PING / FILE_PING: remove failed members > ------------------------------------------ > > Key: JGRP-1956 > URL: https://issues.jboss.org/browse/JGRP-1956 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Reporter: Karsten Ohme > Assignee: Bela Ban > Fix For: 3.6.5 > > > When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there. > SOLUTION: > - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING) > - On a view change: remove all data that's not in the current view -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove failed members

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1956?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1956: -------------------------------- Can you try with the following attributes enabled: ? * {{remove_old_coords_on_view_change}} * {{remove_all_files_on_view_change}} The reason old members are not immediately removed is that these members could have been split away, in a network partition, rather than crashed. If we want a merge to succeed in such a case, it is better to leave information about them in the store. Note that {{TP.logical_addr_cache_max_size}} and {{TP.logical_addr_cache_expiration}} govern when stale entries will be removed. By default, you won't have more than 2000 stale elements in the cache. > S3_PING / FILE_PING: remove failed members > ------------------------------------------ > > Key: JGRP-1956 > URL: https://issues.jboss.org/browse/JGRP-1956 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Reporter: Karsten Ohme > Assignee: Bela Ban > Fix For: 3.6.5 > > > When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there. > SOLUTION: > - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING) > - On a view change: remove all data that's not in the current view -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5220) Tests in testsuite/integration/basic runs more time when -Dtest maven argument is used

by Josef Cacek (JIRA)

[ https://issues.jboss.org/browse/WFLY-5220?page=com.atlassian.jira.plugin.... ] Josef Cacek commented on WFLY-5220: ----------------------------------- Stuart, how it breaks the usage? The correct is only one active surefire exeuction (with {{standalone-full.xml}} profile}}) when the {{-Dtest}} is used - as it's described in the profile comment. {code:xml}  {code} It worked as described in the past, but stopped to work after this change: https://github.com/wildfly/wildfly/commit/005567fe438049426292e4ca270060e... > Tests in testsuite/integration/basic runs more time when -Dtest maven argument is used > -------------------------------------------------------------------------------------- > > Key: WFLY-5220 > URL: https://issues.jboss.org/browse/WFLY-5220 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 10.0.0.Beta2 > Reporter: Josef Cacek > Assignee: Josef Cacek > > Multiple maven-surefire-plugin executions are started when {{-Dtest}} maven switch is used in {{testsuite/integration/basic}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5220) Tests in testsuite/integration/basic runs more time when -Dtest maven argument is used

by Josef Cacek (JIRA)

[ https://issues.jboss.org/browse/WFLY-5220?page=com.atlassian.jira.plugin.... ] Josef Cacek edited comment on WFLY-5220 at 9/2/15 2:24 AM: ----------------------------------------------------------- Stuart, how it breaks the usage? The correct is only one active surefire exeuction (with {{standalone-full.xml}} profile) when the {{-Dtest}} is used - as it's described in the profile comment. {code:xml}  {code} It worked as described in the past, but stopped to work after this change: https://github.com/wildfly/wildfly/commit/005567fe438049426292e4ca270060e... was (Author: jcacek): Stuart, how it breaks the usage? The correct is only one active surefire exeuction (with {{standalone-full.xml}} profile}}) when the {{-Dtest}} is used - as it's described in the profile comment. {code:xml}  {code} It worked as described in the past, but stopped to work after this change: https://github.com/wildfly/wildfly/commit/005567fe438049426292e4ca270060e... > Tests in testsuite/integration/basic runs more time when -Dtest maven argument is used > -------------------------------------------------------------------------------------- > > Key: WFLY-5220 > URL: https://issues.jboss.org/browse/WFLY-5220 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 10.0.0.Beta2 > Reporter: Josef Cacek > Assignee: Josef Cacek > > Multiple maven-surefire-plugin executions are started when {{-Dtest}} maven switch is used in {{testsuite/integration/basic}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5259) truststore path is ignored if provider is not JKS

by Arto Huusko (JIRA)

Arto Huusko created WFLY-5259: --------------------------------- Summary: truststore path is ignored if provider is not JKS Key: WFLY-5259 URL: https://issues.jboss.org/browse/WFLY-5259 Project: WildFly Issue Type: Feature Request Components: ConfigAdmin, Security Affects Versions: 9.0.1.Final Reporter: Arto Huusko Assignee: Thomas Diesler truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. Even standard java supports PKCS12 truststores, where the same problem would occur. So I would suggest that - if provider is JKS, path is mandatory - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1958) RequestCorrelator "channel is not connected" error during shutdown

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1958?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1958: --------------------------- Fix Version/s: 3.6.5 > RequestCorrelator "channel is not connected" error during shutdown > ------------------------------------------------------------------ > > Key: JGRP-1958 > URL: https://issues.jboss.org/browse/JGRP-1958 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.5 > > > Error logged during shutdown of a channel due to RequestCorrelator failing to send a reply: > ERROR [org.jgroups.protocols.UNICAST2] (OOB-17,shared=tcp) couldn't deliver OOB message [dst: server1/web, src: server2/web (4 headers), size=62 bytes, flags=OOB|DONT_BUNDLE|RSVP]: java.lang.IllegalStateException: channel is not connected > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:544) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:600) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] > [incoming JGroups message] > It appears to just be a timing issue between shutdown of the channel and RequestCorrelator processing the message, which triggers a response message. > It would be good to either avoid triggering the exception in the first place, or suppress the error log during shutdown. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5258) Unexpected behavior of negative priorities in container filters

by Andreas Redmer (JIRA)

Andreas Redmer created WFLY-5258: ------------------------------------ Summary: Unexpected behavior of negative priorities in container filters Key: WFLY-5258 URL: https://issues.jboss.org/browse/WFLY-5258 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 9.0.1.Final Environment: Windows/Linux Reporter: Andreas Redmer Assignee: Stuart Douglas Priority: Minor Annotation a class that implements ContainerRequestFilter with @Priority(Integer.MIN_VALUE) works as expected. The filter is executed first. For ContainerResponseFilter it is executed in random order. Priority values should generally be non-negative, with negative values reserved for special meanings such as "undefined" or "not specified". A specification that defines use of the Priority annotation may define the range of allowed priorities and any priority values with special meaning. In this case the behaviour for negative Priorities is inconsistent between the 2 container filters. The correct way to work around this is to annotate: @Priority(0) Even though: many internet tutorials suggest: @Priority(Integer.MIN_VALUE) The implemntation oif logging filter in Glassfish does that too: https://github.com/jersey/jersey/blob/master/core-common/src/main/java/or... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5220) Tests in testsuite/integration/basic runs more time when -Dtest maven argument is used

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5220?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-5220: -------------------------------------- I am reverting this PR because it breaks -Dtest= usage > Tests in testsuite/integration/basic runs more time when -Dtest maven argument is used > -------------------------------------------------------------------------------------- > > Key: WFLY-5220 > URL: https://issues.jboss.org/browse/WFLY-5220 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 10.0.0.Beta2 > Reporter: Josef Cacek > Assignee: Josef Cacek > > Multiple maven-surefire-plugin executions are started when {{-Dtest}} maven switch is used in {{testsuite/integration/basic}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4515) Fix clustering transformers and reenable in mixed-domain tests

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4515?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-4515: --------------------------------- Comment: was deleted (was: New problem: java.lang.AssertionError: [("cache-container" => "*"),("distributed-cache" => "*"),("mixed-keyed-jdbc-store" => "MIXED_KEYED_JDBC_STORE")] Element 'dialect' is not known in target definition) > Fix clustering transformers and reenable in mixed-domain tests > -------------------------------------------------------------- > > Key: WFLY-4515 > URL: https://issues.jboss.org/browse/WFLY-4515 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 9.0.0.Beta2 > Reporter: Kabir Khan > Assignee: Radoslav Husar > Priority: Critical > Fix For: 10.0.0.CR1 > > > When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests. > Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira. > Some info from private mail: > {quote} > However, when transforming that to 7.2.0 by running: > mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite > I get the following error: > 11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [ > ("profile" => "full-ha"), > ("subsystem" => "infinispan"), > ("cache-container" => "server"), > ("transport" => "TRANSPORT") > ] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem] > I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing > /subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp) > and the stack does not get persisted. > It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extensi... so that we can support old configs, but not actually use it on a server using the current version? > {quote} > Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4515) Fix clustering transformers and reenable in mixed-domain tests

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4515?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-4515: -------------------------------------- New problem: java.lang.AssertionError: [("cache-container" => "*"),("distributed-cache" => "*"),("mixed-keyed-jdbc-store" => "MIXED_KEYED_JDBC_STORE")] Element 'dialect' is not known in target definition > Fix clustering transformers and reenable in mixed-domain tests > -------------------------------------------------------------- > > Key: WFLY-4515 > URL: https://issues.jboss.org/browse/WFLY-4515 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 9.0.0.Beta2 > Reporter: Kabir Khan > Assignee: Radoslav Husar > Priority: Critical > Fix For: 10.0.0.CR1 > > > When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests. > Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira. > Some info from private mail: > {quote} > However, when transforming that to 7.2.0 by running: > mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite > I get the following error: > 11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [ > ("profile" => "full-ha"), > ("subsystem" => "infinispan"), > ("cache-container" => "server"), > ("transport" => "TRANSPORT") > ] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem] > I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing > /subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp) > and the stack does not get persisted. > It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extensi... so that we can support old configs, but not actually use it on a server using the current version? > {quote} > Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2015