May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8678) Re-enable tests temporarily disabled in -Delytron run.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-8678?page=com.atlassian.jira.plugin.... ] Jan Kalina updated WFLY-8678: ----------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10049 > Re-enable tests temporarily disabled in -Delytron run. > ------------------------------------------------------ > > Key: WFLY-8678 > URL: https://issues.jboss.org/browse/WFLY-8678 > Project: WildFly > Issue Type: Task > Components: Security, Test Suite > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Blocker > Fix For: 11.0.0.Beta1 > > > The following tests are temporarily ignored: - > Tests in error: > ExportImportJournalTestCase.testExportImportJournal:136->sendMessage:77 » Communication > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > PooledConnectionFactoryStatisticsTestCase.testStatistics:83 » Communication WF... > RemoteNamingEjbTestCase.testDeploymentBinding:140 » Communication WFNAM00018: ... > RemoteNamingEjbTestCase.testIt:99 » Communication WFNAM00018: Failed to connec... > RemoteNamingTestCase.testNestedLookup:109 » Communication WFNAM00018: Failed t... > RemoteNamingTestCase.testRemoteContextLookup:97 » Communication WFNAM00018: Fa... > RemoteNamingTestCase.testRemoteLookup:85 » Communication WFNAM00018: Failed to... > TransactionInflowTestCase.inflowTransactionCommit:138 » IllegalState EJBCLIENT... > TransactionInflowTestCase.inflowTransactionRollback:156 » IllegalState EJBCLIE... > Investigation needs to continue as it actually appears something running before these tests is the cause as running these tests in isolation does not cause a failure. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8678) Re-enable tests temporarily disabled in -Delytron run.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-8678?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-8678: -------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Re-enable tests temporarily disabled in -Delytron run. > ------------------------------------------------------ > > Key: WFLY-8678 > URL: https://issues.jboss.org/browse/WFLY-8678 > Project: WildFly > Issue Type: Task > Components: Security, Test Suite > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Blocker > Fix For: 11.0.0.Beta1 > > > The following tests are temporarily ignored: - > Tests in error: > ExportImportJournalTestCase.testExportImportJournal:136->sendMessage:77 » Communication > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con... > PooledConnectionFactoryStatisticsTestCase.testStatistics:83 » Communication WF... > RemoteNamingEjbTestCase.testDeploymentBinding:140 » Communication WFNAM00018: ... > RemoteNamingEjbTestCase.testIt:99 » Communication WFNAM00018: Failed to connec... > RemoteNamingTestCase.testNestedLookup:109 » Communication WFNAM00018: Failed t... > RemoteNamingTestCase.testRemoteContextLookup:97 » Communication WFNAM00018: Fa... > RemoteNamingTestCase.testRemoteLookup:85 » Communication WFNAM00018: Failed to... > TransactionInflowTestCase.inflowTransactionCommit:138 » IllegalState EJBCLIENT... > TransactionInflowTestCase.inflowTransactionRollback:156 » IllegalState EJBCLIE... > Investigation needs to continue as it actually appears something running before these tests is the cause as running these tests in isolation does not cause a failure. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on JGRP-2162: ----------------------------------- {{Discovery}} could define {{getDefaultSendCacheOnJoin() { return false; } }}, that way TCPPING would override it cleanly. But I agree that overriding parent defaults isn't perfect. You're right that the recommendation is in docs, maybe you could add that to schema docs, too. Also, you could mention that {{send_cache_on_join}} should be set on if you don't provide all hosts. Still, in ideal case, when a node does not find a mapping between the logical and physical address, it should try to find it. Cache is, by nature, something expendable. I'll modify Infinispan configs to get less flaky testsuite in the meantime anyway. > Failed to send broadcast when opening the connection > ---------------------------------------------------- > > Key: JGRP-2162 > URL: https://issues.jboss.org/browse/JGRP-2162 > Project: JGroups > Issue Type: Bug > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 4.0.4 > > Attachments: TcpNio2McastTest.java, infinispan_2.log.gz > > > IRC discussion: > {quote} > bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. > <bela_> rvansa: reproducible? > <rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" > <rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be > <bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit > <bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough > <rvansa> bela_: I don't think it should go over the limit > <rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting > <rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message > {quote} > I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]): > {code:xml} > <TCPPING async_discovery="true" initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800]}" port_range="0"/> > {code} > This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore). > Note that increasing the timeout in request options does not help. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ] James Perkins edited comment on WFCORE-2746 at 5/11/17 11:39 AM: ----------------------------------------------------------------- I'm personally not a big fan of tests that require order to run. Test running in different orders is a good thing as it may expose issues with other tests IMO. For the setup that is what the {{@ServerSetup}} annotation and {{ServerSetupTask}} interface are for. If you need changes before/after a test runs those should be done in the specific test method. There is not need to add a new {{@Test}} method to make these kinds of changes. If there is a good reason to add an {{@InSequence}} type of annotation we can have a look. was (Author: jamezp): I'm personally not a big fan of tests that require order to run. Test running in different orders is a good thing as it may expose issues with other tests IMO. If there is a good reason to add an {{@InSequence}} type of annotation we can have a look. > Move elytron management security tests from full to core > -------------------------------------------------------- > > Key: WFCORE-2746 > URL: https://issues.jboss.org/browse/WFCORE-2746 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security, Test Suite > Reporter: Brian Stansberry > > Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested. > Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723 > There are a number of aspects to this, for which I'll create subtasks. > Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list. > -org.jboss.as.test.integration.security.perimeter.* [2]- > -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase- > -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]- > org.jboss.as.test.integration.security.credentialreference [2] > integration/elytron/ > [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now. > [2] Currently using Arquillian. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-2746: --------------------------------------- I'm personally not a big fan of tests that require order to run. Test running in different orders is a good thing as it may expose issues with other tests IMO. If there is a good reason to add an {{@InSequence}} type of annotation we can have a look. > Move elytron management security tests from full to core > -------------------------------------------------------- > > Key: WFCORE-2746 > URL: https://issues.jboss.org/browse/WFCORE-2746 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security, Test Suite > Reporter: Brian Stansberry > > Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested. > Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723 > There are a number of aspects to this, for which I'll create subtasks. > Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list. > -org.jboss.as.test.integration.security.perimeter.* [2]- > -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase- > -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]- > org.jboss.as.test.integration.security.credentialreference [2] > integration/elytron/ > [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now. > [2] Currently using Arquillian. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2167) Highest seqno is not resent nor recorded on receivers

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-2167?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on JGRP-2167: ----------------------------------- Ok, I'll try to get logs from the failing test to see what happened to STABLE. If I recall correctly it was not lost; it was not sent at all. > Highest seqno is not resent nor recorded on receivers > ----------------------------------------------------- > > Key: JGRP-2167 > URL: https://issues.jboss.org/browse/JGRP-2167 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Radim Vansa > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.4 > > > I am investigating an issue in a stress test which leads me to a situation where in a TCP-based configuration a {{GMS[VIEW]}} is broadcast to all nodes, but it is not received by some of them. Soon after that there's a {{NAKACK2.HIGHEST_SEQNO}} that causes the node that is missing the last seqno to resend it, but the retransmit is not received either. There are no further retries, and generally no NAKACK2 activity until about 30 seconds later (when another node leaves after some timeout in the test). > The receiver does not keep asking for retransmissions until it gets them, but it seems that {{NAKACK2.handleHighestSeqno}} doesn't update {{Table.hr}} (not sure if having highest received set to non-received msg would be legal, though). > The sender uses default value {{NAKACK2.resend_last_seqno_max_times=1}}, and as there are no further mcast messages, the highest sent seqno does not change on sender. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2109) S3_PING: add support for instance metadata

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2109?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2109: -------------------------------- [~rhusar] Don't you worry, I'm already implementing it: https://github.com/jgroups-extras/jgroups-google... :-) > S3_PING: add support for instance metadata > ------------------------------------------ > > Key: JGRP-2109 > URL: https://issues.jboss.org/browse/JGRP-2109 > Project: JGroups > Issue Type: Feature Request > Reporter: Kerem Kacel > Assignee: Bela Ban > Fix For: 4.1 > > > The AWS libraries used by S3_PING do not support authenticating into the AWS API via the EC2 instance profile (implicit credentials stored on the AWS EC2 instance). > The AWS SDK for Java supports instance profile. This eliminates the need for storing AWS access keys in config files. > Are there any plans to add official support for this in JGroups? > Resources: > http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.... > http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html > Example third-party protocols: > https://github.com/tagbangers/jgroups-s3-client-ping > https://github.com/mcacker/jgroups-native-s3-ping -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2170) GOOGLE_PING2

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2170?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2170: --------------------------- Description: New version of GOOGLE_PING based on the official Google Cloud Storage APIs [1]. The existing GOOGLE_PING protocol extends S3_PING which I want to deprecate, so creating GOOGLE_PING2 is a prerequisite to that. Hosting will be at jgroups-extras: https://github.com/jgroups-extras/jgroups-google [1] https://cloud.google.com/storage/docs/apis was: New version of GOOGLE_PING based on the official Google Cloud Storage APIs [1]. The existing GOOGLE_PING protocol extends S3_PING which I want to deprecate, so creating GOOGLE_PING2 is a prerequisite to that. Hosting will be at jgroups-extras. [1] https://cloud.google.com/storage/docs/apis > GOOGLE_PING2 > ------------ > > Key: JGRP-2170 > URL: https://issues.jboss.org/browse/JGRP-2170 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.1 > > > New version of GOOGLE_PING based on the official Google Cloud Storage APIs [1]. The existing GOOGLE_PING protocol extends S3_PING which I want to deprecate, so creating GOOGLE_PING2 is a prerequisite to that. > Hosting will be at jgroups-extras: https://github.com/jgroups-extras/jgroups-google > [1] https://cloud.google.com/storage/docs/apis -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1138) Revise configuration options of ssl-context in wildfly-config.xml

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1138?page=com.atlassian.jira.plugin.s... ] Jan Kalina reassigned ELY-1138: ------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Revise configuration options of ssl-context in wildfly-config.xml > ----------------------------------------------------------------- > > Key: ELY-1138 > URL: https://issues.jboss.org/browse/ELY-1138 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > Comparing subsystem configuration options of client-ssl-context to wildfly-config.xml I am missing these attributes: > * client-ssl-context > ** use-cipher-suites-order > ** maximum-session-cache-size > ** session-timeout > * key-managers/trust-managers: > ** algorithm (is IBM - IBMX509 handled properly? e.g. *ManagerFactory.getDefaultAlgorithm() is called internally) > * trust-manager > ** certificate-revocation-list > * key-managers > ** key-password -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region

by Mark Morris (JIRA)

[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ] Mark Morris commented on JGRP-1914: ----------------------------------- Yes I agree you should remove it. -Mark > S3_PING doesn't work with S3 buckets created in Frankfurt region > ----------------------------------------------------------------- > > Key: JGRP-1914 > URL: https://issues.jboss.org/browse/JGRP-1914 > Project: JGroups > Issue Type: Bug > Reporter: Gleb Leonov > Assignee: Bela Ban > Fix For: 4.1 > > Attachments: AWS4.png > > > I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 May 2017