[JBoss JIRA] (JGRP-2205) DISCARD ignores the DONT_LOOPBACK transient flag
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2205?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2205 at 7/24/17 12:11 PM:
----------------------------------------------------------
Are you suggesting to _not_ drop the message in {{down(Message)}} if {{discard_all == true}}, but later in {{up(Message)}} / {{up(MessageBatch}}?
was (Author: belaban):
Are you suggesting to _not_ drop the message in {{down(Message)}} if {{discard_all == true}}, but later in {{up(Message()}} / {{up(MessageBatch}}?
> DISCARD ignores the DONT_LOOPBACK transient flag
> ------------------------------------------------
>
> Key: JGRP-2205
> URL: https://issues.jboss.org/browse/JGRP-2205
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 4.0.5
>
>
> When {{discard_all = true}}, {{DISCARD}} does its own loopback, and doesn't check for {{DONT_LOOPBACK}} like {{TP}}. It always sends the message back up, even if {{excludeItself = false}}.
> If possible, {{DISCARD}} should just set the message destination to the local address and pass the message down. That way, {{TP}} would decide make the loopback decision, and using the {{TP}} thread pool would also make the thread name nicer in the logs. (Currently the thread name is {{Thread-n}}, which means searching for the test name in our test suite's log misses some messages.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2205) DISCARD ignores the DONT_LOOPBACK transient flag
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2205?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2205 at 7/24/17 12:11 PM:
----------------------------------------------------------
Are you suggesting to _not_ drop the message in {{down(Message)}} if {{discard_all == true}}, but later in {{up(Message)}} / {{up(MessageBatch)}}?
was (Author: belaban):
Are you suggesting to _not_ drop the message in {{down(Message)}} if {{discard_all == true}}, but later in {{up(Message)}} / {{up(MessageBatch}}?
> DISCARD ignores the DONT_LOOPBACK transient flag
> ------------------------------------------------
>
> Key: JGRP-2205
> URL: https://issues.jboss.org/browse/JGRP-2205
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 4.0.5
>
>
> When {{discard_all = true}}, {{DISCARD}} does its own loopback, and doesn't check for {{DONT_LOOPBACK}} like {{TP}}. It always sends the message back up, even if {{excludeItself = false}}.
> If possible, {{DISCARD}} should just set the message destination to the local address and pass the message down. That way, {{TP}} would decide make the loopback decision, and using the {{TP}} thread pool would also make the thread name nicer in the logs. (Currently the thread name is {{Thread-n}}, which means searching for the test name in our test suite's log misses some messages.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2204) Deprecate DONT_BUNDLE message flag
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2204?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2204.
----------------------------
Resolution: Won't Fix
Sorry: this JIRA is an oversight; we still removed messages marked with {{OOB}} and {{DONT_BUNDLE}} from message batches and send them up in separate threads.
Closing this JIRA now...
> Deprecate DONT_BUNDLE message flag
> ----------------------------------
>
> Key: JGRP-2204
> URL: https://issues.jboss.org/browse/JGRP-2204
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.5
>
>
> Although {{Message$Flag.DONT_BUNDLE}} is ignored by the transports, it is still a valid message flag.
> Deprecate this flag and remove all uses of it by JGroups itself. Can't remove it until the next major version, as this would break client code.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-534) Some tests fail with ExceptionInInitializerError with JMockit 1.22 for IBM JDK
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-534?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-534:
------------------------------------
Assignee: Peter Palaga (was: Darran Lofthouse)
> Some tests fail with ExceptionInInitializerError with JMockit 1.22 for IBM JDK
> ------------------------------------------------------------------------------
>
> Key: ELY-534
> URL: https://issues.jboss.org/browse/ELY-534
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta6
> Reporter: Ondrej Lukas
> Assignee: Peter Palaga
> Priority: Minor
> Fix For: 1.2.0.Beta1
>
>
> Some tests fail with java.lang.ExceptionInInitializerError on IBM JDK.
> Stacktrace (for OAuth2SecurityRealmTest):
> {code}
> java.lang.ExceptionInInitializerError
> at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137)
> at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126)
> at org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest.configureTokenIntrospectionEndpoint(OAuth2SecurityRealmTest.java:198)
> at org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest.configureReplayTokenIntrospection(OAuth2SecurityRealmTest.java:188)
> at org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest.testBasicActiveToken(OAuth2SecurityRealmTest.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.lang.IllegalStateException: To run on IBM J9 VM, add <IBM SDK>/lib/tools.jar to the runtime classpath (before jmockit), or use -javaagent:/mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/5fe75d5a/maven-repository/org/jmockit/jmockit/1.22/jmockit-1.22.jar
> at mockit.internal.startup.AgentLoader.loadAgent(AgentLoader.java:49)
> at mockit.internal.startup.Startup.verifyInitialization(Startup.java:172)
> at mockit.MockUp.<clinit>(MockUp.java:94)
> ... 27 more
> {code}
> This is probably only test issue.
> Affected tests:
> org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest
> org.wildfly.security.sasl.digest.CompatibilityClientTest
> org.wildfly.security.sasl.digest.CompatibilityServerTest
> org.wildfly.security.sasl.entity.EntityTest
> org.wildfly.security.sasl.gssapi.compatibility.BasicAuthTest
> org.wildfly.security.sasl.gssapi.compatibility.BasicConfidenceTest
> org.wildfly.security.sasl.gssapi.compatibility.BasicIntegrityTest
> org.wildfly.security.sasl.gssapi.compatibility.NoServerAuthTest
> org.wildfly.security.sasl.otp.OTPTest
> org.wildfly.security.sasl.scram.ScramClientCompatibilityTest
> org.wildfly.security.sasl.scram.ScramServerCompatibilityTest
> It seems that this issue can be fixed by adding -{{javaagent:$\{USED_MAVEN_REPO\}/org/jmockit/jmockit/1.22/jmockit-1.22.jar}} as argLine option for Maven Surefire Plugin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-534) Some tests fail with ExceptionInInitializerError with JMockit 1.22 for IBM JDK
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-534?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-534:
---------------------------------
Fix Version/s: 1.2.0.Beta1
> Some tests fail with ExceptionInInitializerError with JMockit 1.22 for IBM JDK
> ------------------------------------------------------------------------------
>
> Key: ELY-534
> URL: https://issues.jboss.org/browse/ELY-534
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta6
> Reporter: Ondrej Lukas
> Assignee: Peter Palaga
> Priority: Minor
> Fix For: 1.2.0.Beta1
>
>
> Some tests fail with java.lang.ExceptionInInitializerError on IBM JDK.
> Stacktrace (for OAuth2SecurityRealmTest):
> {code}
> java.lang.ExceptionInInitializerError
> at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137)
> at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126)
> at org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest.configureTokenIntrospectionEndpoint(OAuth2SecurityRealmTest.java:198)
> at org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest.configureReplayTokenIntrospection(OAuth2SecurityRealmTest.java:188)
> at org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest.testBasicActiveToken(OAuth2SecurityRealmTest.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.lang.IllegalStateException: To run on IBM J9 VM, add <IBM SDK>/lib/tools.jar to the runtime classpath (before jmockit), or use -javaagent:/mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/5fe75d5a/maven-repository/org/jmockit/jmockit/1.22/jmockit-1.22.jar
> at mockit.internal.startup.AgentLoader.loadAgent(AgentLoader.java:49)
> at mockit.internal.startup.Startup.verifyInitialization(Startup.java:172)
> at mockit.MockUp.<clinit>(MockUp.java:94)
> ... 27 more
> {code}
> This is probably only test issue.
> Affected tests:
> org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest
> org.wildfly.security.sasl.digest.CompatibilityClientTest
> org.wildfly.security.sasl.digest.CompatibilityServerTest
> org.wildfly.security.sasl.entity.EntityTest
> org.wildfly.security.sasl.gssapi.compatibility.BasicAuthTest
> org.wildfly.security.sasl.gssapi.compatibility.BasicConfidenceTest
> org.wildfly.security.sasl.gssapi.compatibility.BasicIntegrityTest
> org.wildfly.security.sasl.gssapi.compatibility.NoServerAuthTest
> org.wildfly.security.sasl.otp.OTPTest
> org.wildfly.security.sasl.scram.ScramClientCompatibilityTest
> org.wildfly.security.sasl.scram.ScramServerCompatibilityTest
> It seems that this issue can be fixed by adding -{{javaagent:$\{USED_MAVEN_REPO\}/org/jmockit/jmockit/1.22/jmockit-1.22.jar}} as argLine option for Maven Surefire Plugin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2422) Credential Store alias name in camel case leads to AssertionError.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2422?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFCORE-2422:
--------------------------------------
[~hsvabek] That wasn't quite what I was asking. I was wondering what change was associated with resolving this jira? There is no PR/commit associated with resolving this issue. One would assume it was an upstream fix, but nothing is linked.
> Credential Store alias name in camel case leads to AssertionError.
> ------------------------------------------------------------------
>
> Key: WFCORE-2422
> URL: https://issues.jboss.org/browse/WFCORE-2422
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Fix For: 3.0.0.Beta29
>
>
> Credential Store alias name in camel case leads to AssertionError.
> I am not able to reproduce it over jboss-cli but I can reproduce it in tests.
> You can see to attachment.
> *How to reproduce*
> * unzip uppercasealias.zip to wildfly/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/credential/store
> * cd wildfly/testsuite/integration/basic
> * mvn test -Dtest=CredentialStoreTestCase
> In log you can see this:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "testCamelCase"),
> ("alias" => "camelcasenotationalias")
> ]): java.lang.AssertionError
> at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:87)
> at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:99)
> at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1841)
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1739)
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1698)
> at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:575)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:270)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.execute(CredentialStoreAliasDefinition.java:209)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1390)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:419)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:240)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:193)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:240)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:212)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months