[JBoss JIRA] (ELY-983) WildFlySasl.MECHANISM_QUERY_ALL is taken into account in ExternalSasl*Factory.createSasl* methods
by Josef Cacek (JIRA)
Josef Cacek created ELY-983:
-------------------------------
Summary: WildFlySasl.MECHANISM_QUERY_ALL is taken into account in ExternalSasl*Factory.createSasl* methods
Key: ELY-983
URL: https://issues.jboss.org/browse/ELY-983
Project: WildFly Elytron
Issue Type: Bug
Reporter: Josef Cacek
Assignee: Darran Lofthouse
The description of {{MECHANISM_QUERY_ALL}} filtering property says:
{quote}
This flag is only effective on calls to SaslServerFactory.getMechanismNames(Map) or SaslClientFactory.getMechanismNames(Map) for Elytron-provided SASL factories.
{quote}
It's not true for EXTERNAL SASL mechanism factories, where it's taken into account also in {{createSaslServer/Client}} methods.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-5319:
------------------------------------
Just challenging myself and my assertion in the negativeTxTimeoutVerifyReaperThreadCanceledTxTest method. Current code is:
{code}
/**
* Repeat the same test as test_negativeTxTimeoutTest but also ensure that the reaper thread canceled the tx.
* If this test fails, it could be that the tx reaper thread name changed or we are using a different tx manager.
*
* @throws Exception
*/
// @Ignore // WFLY-5319 is for fixing this test (see failure https://gist.github.com/scottmarlow/6409290362f35f2d1320)
@Test
@InSequence(3)
public void test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest() throws Exception {
TestEntityManager.clearState();
assertFalse("entity manager state is not reset", TestEntityManager.getClosedByReaperThread());
SFSB1 sfsb1 = lookup("ejbjar/SFSB1", SFSB1.class);
try {
sfsb1.createEmployeeWaitForTxTimeout(true, "Wily", "1 Appletree Lane", 10);
} catch (Exception e) { // ignore the tx rolled back exception
//
}
assertFalse("entity manager should not of been closed by the reaper thread", TestEntityManager.getClosedByReaperThread());
assertTrue("transaction was canceled by reaper thread", SFSB1.isAfterCompletionCalledByTMTimeoutThread());
}
{code}
We are failing the second assertion "assertTrue("transaction was canceled by reaper thread", SFSB1.isAfterCompletionCalledByTMTimeoutThread())". I am trying to get more information out of this test case by recording the thread name of which the afterCompletion was called from (should be the reaper thread or application thread. Once we have the thread name from the failing case, we can determine next steps to update the test.
> fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5319
> URL: https://issues.jboss.org/browse/WFLY-5319
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Attachments: server.zip
>
>
> https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.... ]
Scott Marlow edited comment on WFLY-5319 at 3/1/17 12:12 PM:
-------------------------------------------------------------
Attached server.log which is from following steps:
1. Update testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/mockprovider/txtimeout/TxTimeoutTestCase.java, delete the @Ignore on the class:
{quote} @Ignore // WFLY-5319 is for fixing this test {quote}
2. Change into folder testsuite/integration/basic
3. mvn clean install -Dtest=org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase
I could pass this test locally on my T540 laptop but on test machine, I was able to see the failure:
{quote}
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase
Tests run: 3, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 3.866 sec <<< FAILURE! - in org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase
test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase) Time elapsed: 1.409 sec <<< FAILURE!
java.lang.AssertionError: transaction was canceled by reaper thread
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(TxTimeoutTestCase.java:173)
Results :
Failed tests:
TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest:173 transaction was canceled by reaper thread
{quote}
See attached server.log which is from this test run. I'm not sure if [WFLY-6212] is at the root of the problem or something else.
was (Author: smarlow):
Attached server.log which is from following steps:
1. Update testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/mockprovider/txtimeout/TxTimeoutTestCase.java, delete the @Ignore on the class:
{quote} @Ignore // WFLY-5319 is for fixing this test {quote}
2. Change into folder testsuite/integration/basic
3. mvn clean install -Dtest=org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase
I could pass this test locally on my T540 laptop but on test machine, I was able to see the failure:
{quote}
test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase) Time elapsed: 1.409 sec <<< FAILURE!
java.lang.AssertionError: transaction was canceled by reaper thread
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(TxTimeoutTestCase.java:173)
{quote}
See attached server.log which is from this test run. I'm not sure if [WFLY-6212] is at the root of the problem or something else.
> fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5319
> URL: https://issues.jboss.org/browse/WFLY-5319
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Attachments: server.zip
>
>
> https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2161:
--------------------------------
git bisect shows the offending commit to be {{509cfe}}; this is where {{message_processing_policy}} in the transport was set to "max" (from "submit") as default.
Changing this back to "max" fixes the issue.
The problem is that {{MaxOneThreadPerSender}} creates message batches for each sender's address in its table and uses the batches to queue messages when a message for a given sender is already being processed.
However, the dest and sender's address of those batches is not changed on a disconnect-connect sequence, which results in messages being sent to old UUIDs, which are discarded by the transport logic when comparing the destination address of a batch with the local address.
A simple solution is to remove entries from that table on a disconnect and on a view change (remove entries for left members).
> UNICAST3: message delivery fails after disconnect-connect sequence
> ------------------------------------------------------------------
>
> Key: JGRP-2161
> URL: https://issues.jboss.org/browse/JGRP-2161
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.1, 4.0.1
>
>
> When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-5319:
------------------------------------
Attached server.log which is from following steps:
1. Update testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/mockprovider/txtimeout/TxTimeoutTestCase.java, delete the @Ignore on the class:
{quote} @Ignore // WFLY-5319 is for fixing this test {quote}
2. Change into folder testsuite/integration/basic
3. mvn clean install -Dtest=org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase
I could pass this test locally on my T540 laptop but on test machine, I was able to see the failure:
{quote}
test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase) Time elapsed: 1.409 sec <<< FAILURE!
java.lang.AssertionError: transaction was canceled by reaper thread
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(TxTimeoutTestCase.java:173)
{quote}
See attached server.log which is from this test run. I'm not sure if [WFLY-6212] is at the root of the problem or something else.
> fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5319
> URL: https://issues.jboss.org/browse/WFLY-5319
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Attachments: server.zip
>
>
> https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-8238:
----------------------------------------
[~thofman] I haven't looked at the code involved here at all, but just as an FYI -- we only added overall validation of requires and alternatives into the kernel in the last couple years. (See ValidateModelStepHandler in WildFly Core.) So since that didn't exist for years, there's a fair amount of custom validation code scattered around the code base from when devs saw a particular need for some validation check. When you find that kind of thing, and it sounds like you have here, it's best to investigate with the component lead whether the validation is meant to do anything different from what the kernel now does. If it isn't, strongly consider stripping it out and relying on the kernel.
> Unable to undefine credential-reference
> ---------------------------------------
>
> Key: WFLY-8238
> URL: https://issues.jboss.org/browse/WFLY-8238
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Security
> Reporter: Claudio Miranda
> Assignee: Tomas Hofman
>
> A bridge is added and a credential-reference is set.
> However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value.
> Also neither credential-reference and password are required=true, so they may be undefined.
> {code}
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ)
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1})
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."},
> "rolled-back" => true
> }
> {code}
> The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference
> {code}
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1)
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."},
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months