[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-43:
----------------------------------------
For (2) how about NORMAL?
For WFCORE-1106 for internal use I ended up need a different enum that covered the same concept and I ended up using 'NORMAL'
https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO...
That's not definitive or anything; ^^^ is an internal enum and TBH I didn't think that hard about the NORMAL name. ;)
"SYNCHRONIZED" is valid; agree it's a bit heavy though. "IN_SYNC"? Do you like boy bands? Or hearing lots of boy band jokes? ;)
Re: 1) this is the more important question. A simple value like "NORMAL" is only ok if the name of the attribute makes it pretty clear what it is that's normal. So, not 'process-state'. We already have a 'running-mode' for --admin-only vs not. 'run-state' seems too vague too. Brainstorming I come up with 'configuration-sync' but I'm not going to pretend that's good.
Maybe 'configuration-state"? That's still a bit weird but this is all about the state of the runtime with respect to the persistent configuration.
A main goal is to come up with something where if we add some new feature and need to describe some state, we don't get a name conflict again.
Haha, now I remember why this issue is 21 months old!
> Clarify the meaning of the 'server-state' and 'host-state' attributes
> ---------------------------------------------------------------------
>
> Key: WFCORE-43
> URL: https://issues.jboss.org/browse/WFCORE-43
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html)
> "I do think these are orthogonal and should not be combined.
> The existing attribute is fundamentally about how the state of the
> runtime services relates to the persistent configuration.
> STARTING == out of sync due to still getting in sync during start
> RUNNING == in sync
> RELOAD_REQUIRED = out of sync, needs a reload to get in sync
> RESTART_REQUIRED = out of sync, needs a full process restart to get in sync
> There are two problems though with the existing attribute that exposes this:
> 1) It's named "server-state" on a server and "host-state" on a Host
> Controller. Really crappy name; way too broad.
> That's fixable by creating a new attribute and making the old one an
> alias for compatibility purposes.
> 2) The RUNNING state is really poorly named.
> The could perhaps be fixed by coming up with a new name and translating
> it back to "RUNNING" in the handlers for the legacy "server-state" and
> "host-state" attributes."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-462) LDAP realm should use JNDI to obtain LdapContext
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-462?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-462:
---------------------------
Description:
LDAP realm should use JNDI to obtain LdapContext (as JDBC realm use datasource) - configuration of connection should be outside of Elytron configuration.
(requested by Darran on F2F)
was:
LDAP realm should use naming subsystem (as JDBC realm use datasource)
(requested by Darran on F2F)
> LDAP realm should use JNDI to obtain LdapContext
> ------------------------------------------------
>
> Key: ELY-462
> URL: https://issues.jboss.org/browse/ELY-462
> Project: WildFly Elytron
> Issue Type: Task
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> LDAP realm should use JNDI to obtain LdapContext (as JDBC realm use datasource) - configuration of connection should be outside of Elytron configuration.
> (requested by Darran on F2F)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ]
Ken Wills commented on WFCORE-43:
---------------------------------
[~bstansberry]
I've got a working patch for this, but the naming is being a bit problematic:
(1) server-state / host-state: My initial thought was to name this status, to match the status attribute on servers, but reading the mail archives this seems to be thought overly broad. Alternatives could be process-state, or run-state or running-mode, still thinking about this one. It seems that process-state would be a good match for both.
(2) new state to replace the running state: I've just got a placeholder for now, until we settle on a final name, the mail archives again talk a lot about it being in-sync, / out of sync so perhaps using something like 'synchronized' would work, but it seems overly-complicated sounding. (alternatives , up-to-date, config-synced ... others?)
> Clarify the meaning of the 'server-state' and 'host-state' attributes
> ---------------------------------------------------------------------
>
> Key: WFCORE-43
> URL: https://issues.jboss.org/browse/WFCORE-43
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html)
> "I do think these are orthogonal and should not be combined.
> The existing attribute is fundamentally about how the state of the
> runtime services relates to the persistent configuration.
> STARTING == out of sync due to still getting in sync during start
> RUNNING == in sync
> RELOAD_REQUIRED = out of sync, needs a reload to get in sync
> RESTART_REQUIRED = out of sync, needs a full process restart to get in sync
> There are two problems though with the existing attribute that exposes this:
> 1) It's named "server-state" on a server and "host-state" on a Host
> Controller. Really crappy name; way too broad.
> That's fixable by creating a new attribute and making the old one an
> alias for compatibility purposes.
> 2) The RUNNING state is really poorly named.
> The could perhaps be fixed by coming up with a new name and translating
> it back to "RUNNING" in the handlers for the legacy "server-state" and
> "host-state" attributes."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2034) SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2034?page=com.atlassian.jira.plugin.... ]
Bela Ban reassigned JGRP-2034:
------------------------------
Fix Version/s: 3.6.9
4.0
Assignee: Tristan Tarrant (was: Bela Ban)
Tristan, can you take a look?
> SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8
> ------------------------------------------------------------------------------------------
>
> Key: JGRP-2034
> URL: https://issues.jboss.org/browse/JGRP-2034
> Project: JGroups
> Issue Type: Bug
> Reporter: Ivan Straka
> Assignee: Tristan Tarrant
> Fix For: 3.6.9, 4.0
>
>
> We see these two tests failing on IBM jdk 1.8
> org.jgroups.protocols.SASLTest-functional
> org.jgroups.protocols.SASL_SimpleAuthorizingCallbackTest-functional
> This issue may be related to https://issues.jboss.org/browse/JGRP-1993 somehow.
> There is standard output of tests.
> {code}
> ------------- testSASLDigestMD5 -----------
> -------------------------------------------------------------------
> GMS: address=A, cluster=SaslTest
> -------------------------------------------------------------------
> 521823 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member
> 521823 [DEBUG] GMS: A: installing view [A|0] (1) [A]
> 521823 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> -------------------------------------------------------------------
> GMS: address=B, cluster=SaslTest
> -------------------------------------------------------------------
> 521825 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done]
> 521826 [DEBUG] GMS: B: sending JOIN(B) to A
> 521826 [TRACE] SASL: B: received CHALLENGE from A
> 521827 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 524826 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1
> 524827 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done]
> 524827 [DEBUG] GMS: B: sending JOIN(B) to A
> 524828 [TRACE] SASL: B: received CHALLENGE from A
> 524828 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 526826 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@ad737f58
> ------------- testSASLDigestMD5Failure -----------
> -------------------------------------------------------------------
> GMS: address=A, cluster=SaslTest
> -------------------------------------------------------------------
> 529863 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member
> 529864 [DEBUG] GMS: A: installing view [A|0] (1) [A]
> 529864 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> -------------------------------------------------------------------
> GMS: address=B, cluster=SaslTest
> -------------------------------------------------------------------
> 529866 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done]
> 529866 [DEBUG] GMS: B: sending JOIN(B) to A
> 529867 [TRACE] SASL: B: received CHALLENGE from A
> 529867 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 532867 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1
> 532867 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done]
> 532867 [DEBUG] GMS: B: sending JOIN(B) to A
> 532868 [TRACE] SASL: B: received CHALLENGE from A
> 532869 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 534867 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@6f6c2511
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-972) CDI annotations are not following CDI scopes
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-972?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-972:
------------------------------------
Can you please send a PR adding a new example in drools-examples-cdi so I could start working from there?
> CDI annotations are not following CDI scopes
> --------------------------------------------
>
> Key: DROOLS-972
> URL: https://issues.jboss.org/browse/DROOLS-972
> Project: Drools
> Issue Type: Feature Request
> Reporter: Mauricio Salatino
> Assignee: Mario Fusco
>
> I'm wondering if it is just a missing feature of if there is a technical limitation why we are not following the CDI scopes approach.
> To be concrete what I wanted to achieve is to have
> Something like this:
> @Inject
> @KReleaseId(groupId = "xxx", artifactId = "xxxxx", version = "1.0-SNAPSHOT")
> @KSession
> private KieSession kSession;
> Inside a bean with @ApplicationScoped.. that works well because the KieSession is application scoped and shared between different requests, but now when I do
> @RequestScoped or @SessionScoped the KieSession is still shared :(
> I imagine that supporting these two scopes should be fairly easy from the CDI point of view:
> 1) @RequestScoped: just recreate the session everytime and look for the @ReleaseId everytime, because the idea is that if the ReleaseId is updated, the new request will need to load the new ReleaseId artifact
> 2) @BusinessSessionScoped: the session will have an ID and just a check is needed, if the session exist just use the KieSession registered for that ID, if it doesn't exist create a new one. Notice that I didn't use the existing @SessionScoped because that is usually tied to the HTTPSession, which might be another case.
> The lack of scopes also interfere with Arquillian for CDI testing, the @Ksession annotation seems to be creating a singleton, so when JUnit fork to execute several tests in parallel the @Injected @Ksession is shared among all the tests :(
> I'm sure that you guys already know about this, but I just wrote it down to state clear what the user expectations are regarding this and also to clarify my thoughts. If you guys can guide me and give me some pointers I can even help on this side.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2034) SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8
by Ivan Straka (JIRA)
Ivan Straka created JGRP-2034:
---------------------------------
Summary: SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8
Key: JGRP-2034
URL: https://issues.jboss.org/browse/JGRP-2034
Project: JGroups
Issue Type: Bug
Reporter: Ivan Straka
Assignee: Bela Ban
We see these two tests failing on IBM jdk 1.8
org.jgroups.protocols.SASLTest-functional
org.jgroups.protocols.SASL_SimpleAuthorizingCallbackTest-functional
This issue may be related to https://issues.jboss.org/browse/JGRP-1993 somehow.
There is standard output of tests.
{code}
------------- testSASLDigestMD5 -----------
-------------------------------------------------------------------
GMS: address=A, cluster=SaslTest
-------------------------------------------------------------------
521823 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member
521823 [DEBUG] GMS: A: installing view [A|0] (1) [A]
521823 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
-------------------------------------------------------------------
GMS: address=B, cluster=SaslTest
-------------------------------------------------------------------
521825 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done]
521826 [DEBUG] GMS: B: sending JOIN(B) to A
521826 [TRACE] SASL: B: received CHALLENGE from A
521827 [WARN] SASL: B: failed to validate CHALLENGE from A, token
javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
Caused by: java.io.IOException: Invalid realm A
at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
... 16 more
524826 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1
524827 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done]
524827 [DEBUG] GMS: B: sending JOIN(B) to A
524828 [TRACE] SASL: B: received CHALLENGE from A
524828 [WARN] SASL: B: failed to validate CHALLENGE from A, token
javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
Caused by: java.io.IOException: Invalid realm A
at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
... 16 more
526826 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@ad737f58
------------- testSASLDigestMD5Failure -----------
-------------------------------------------------------------------
GMS: address=A, cluster=SaslTest
-------------------------------------------------------------------
529863 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member
529864 [DEBUG] GMS: A: installing view [A|0] (1) [A]
529864 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
-------------------------------------------------------------------
GMS: address=B, cluster=SaslTest
-------------------------------------------------------------------
529866 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done]
529866 [DEBUG] GMS: B: sending JOIN(B) to A
529867 [TRACE] SASL: B: received CHALLENGE from A
529867 [WARN] SASL: B: failed to validate CHALLENGE from A, token
javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
Caused by: java.io.IOException: Invalid realm A
at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
... 16 more
532867 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1
532867 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done]
532867 [DEBUG] GMS: B: sending JOIN(B) to A
532868 [TRACE] SASL: B: received CHALLENGE from A
532869 [WARN] SASL: B: failed to validate CHALLENGE from A, token
javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
Caused by: java.io.IOException: Invalid realm A
at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
... 16 more
534867 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@6f6c2511
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month