[JBoss JIRA] (WFCORE-2224) Management issues on host after enabling RBAC
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2224?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved JBEAP-8421 to WFCORE-2224:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2224 (was: JBEAP-8421)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 3.0.0.Alpha16
(was: 7.1.0.DR10)
Affects Testing: (was: Blocks Testing)
> Management issues on host after enabling RBAC
> ---------------------------------------------
>
> Key: WFCORE-2224
> URL: https://issues.jboss.org/browse/WFCORE-2224
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Alpha16
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: eap71_alpha
> Fix For: 3.0.0.Alpha20
>
>
> When enabling RBAC ({{/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)}}), it is not possible to add role mappings:
> {code}
> [domain@localhost:9990 /] /core-service=management/access=authorization/role-mapping=Maintainer:add()
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {
> "server-one" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found",
> "server-two" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found"
> }}}}}},
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {
> "server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found",
> "rolled-back" => true
> }},
> "server-two" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found",
> "rolled-back" => true
> }}
> }}}}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2224) Management issues on host after enabling RBAC
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2224?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2224:
-------------------------------------
Fix Version/s: 3.0.0.Alpha20
> Management issues on host after enabling RBAC
> ---------------------------------------------
>
> Key: WFCORE-2224
> URL: https://issues.jboss.org/browse/WFCORE-2224
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Alpha16
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: eap71_alpha
> Fix For: 3.0.0.Alpha20
>
>
> When enabling RBAC ({{/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)}}), it is not possible to add role mappings:
> {code}
> [domain@localhost:9990 /] /core-service=management/access=authorization/role-mapping=Maintainer:add()
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {
> "server-one" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found",
> "server-two" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found"
> }}}}}},
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {
> "server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found",
> "rolled-back" => true
> }},
> "server-two" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found",
> "rolled-back" => true
> }}
> }}}}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2223) Setting JBOSS_MODULEPATH is lost for second start of embed-server
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2223?page=com.atlassian.jira.plugi... ]
Josef Cacek updated WFCORE-2223:
--------------------------------
Steps to Reproduce:
{code}
unzip -q jboss-eap-7.0.0.zip
cp -r jboss-eap-7.0/ jboss-eap-7.0-no-modules
rm -rf jboss-eap-7.0-no-modules/modules/
export JBOSS_MODULEPATH=`pwd`/jboss-eap-7.0/modules
jboss-eap-7.0-no-modules/bin/jboss-cli.sh << EOT
embed-server
stop-embedded-server
embed-server
stop-embedded-server
EOT
{code}
The same behavior is if you provide the commands in a script and use {{--file=}} JBoss CLI argument.
was:
{code}
unzip -q jboss-eap-7.0.0.zip
cp -r jboss-eap-7.0/ jboss-eap-7.0-no-modules
rm -rf jboss-eap-7.0-no-modules/modules/
export JBOSS_MODULEPATH=`pwd`/jboss-eap-7.0/modules
jboss-eap-7.0-no-modules/bin/jboss-cli.sh << EOT
embed-server
stop-embedded-server
embed-server
stop-embedded-server
EOT
The same behavior is if you provide the commands in a script and use {{--file=}} JBoss CLI argument.
> Setting JBOSS_MODULEPATH is lost for second start of embed-server
> -----------------------------------------------------------------
>
> Key: WFCORE-2223
> URL: https://issues.jboss.org/browse/WFCORE-2223
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules
> Reporter: Josef Cacek
> Assignee: David Lloyd
> Priority: Critical
>
> When {{embed-server}} command is used more times in the CLI and a custom {{JBOSS_MODULEPATH}} is configured, then only the first server start uses the correct module path.
> The subsequent `embed-server` call results in error:
> {code}
> Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on embedded process: WFLYSRV0118: Determined modules directory does not exist: /tmp/jboss-eap-7.0-no-modules/modules
> {code}
> Using the {{JBOSS_MODULEPATH}} environment variable is documented in https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2223) Setting JBOSS_MODULEPATH is lost for second start of embed-server
by Josef Cacek (JIRA)
Josef Cacek created WFCORE-2223:
-----------------------------------
Summary: Setting JBOSS_MODULEPATH is lost for second start of embed-server
Key: WFCORE-2223
URL: https://issues.jboss.org/browse/WFCORE-2223
Project: WildFly Core
Issue Type: Bug
Components: Modules, CLI
Reporter: Josef Cacek
Assignee: David Lloyd
Priority: Critical
When {{embed-server}} command is used more times in the CLI and a custom {{JBOSS_MODULEPATH}} is configured, then only the first server start uses the correct module path.
The subsequent `embed-server` call results in error:
{code}
Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on embedded process: WFLYSRV0118: Determined modules directory does not exist: /tmp/jboss-eap-7.0-no-modules/modules
{code}
Using the {{JBOSS_MODULEPATH}} environment variable is documented in https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1483) Recursive removal doesn't deal with reload-required cleanly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1483?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1483:
-------------------------------------
Description:
There's a flaw in the WFCORE-808 recursive removal feature when it comes to reload-required.
The problem is some of the resources recursively removed can require a reload while others don't, with the result that you get a semi-random set of changes to the runtime. This is particularly an issue if the parent resource requires reload and children don't. So based on the parent resource description the user may be expecting no runtime changes but instead some services are removed.
This is tricky because when the Stage.RUNTIME steps execute for the child resources, they don't know if their parents are going to require a reload. We can probably use a OperationContext attachment of some sort to communicate information between steps associated with a recursive remove, but even with that kind of thing in place, unless we change how AbstractRemoveStepHandler works (likely breaking subclasses) at the time the child decides whether or not to require reload it's not going to know what the parents will decide.
was:
There's a flaw in the WFCORE-808 recursive removal feature when it comes to reload-required.
The problem is some of the resources recursively removed can require a reload while others don't, with the result that you get a semi-random set of changes to the runtime. This is particularly an issue if the parent resource requires reload and children don't. So based on the parent resource description the user may be expecting no runtime changes but instead some services are removed.
This is tricky because when the Stage.RUNTIME steps execute for the child resources, they don't know if their parents are going to require a reload. We can probably use a OperationContext attachment of some sort to communicate information between steps associated with a recursive reload, but even with that kind of thing in place, unless we change how AbstractRemoveStepHandler works (likely breaking subclasses) at the time the child decides whether or not to require reload it's not going to know what the parents will decide.
> Recursive removal doesn't deal with reload-required cleanly
> -----------------------------------------------------------
>
> Key: WFCORE-1483
> URL: https://issues.jboss.org/browse/WFCORE-1483
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
>
> There's a flaw in the WFCORE-808 recursive removal feature when it comes to reload-required.
> The problem is some of the resources recursively removed can require a reload while others don't, with the result that you get a semi-random set of changes to the runtime. This is particularly an issue if the parent resource requires reload and children don't. So based on the parent resource description the user may be expecting no runtime changes but instead some services are removed.
> This is tricky because when the Stage.RUNTIME steps execute for the child resources, they don't know if their parents are going to require a reload. We can probably use a OperationContext attachment of some sort to communicate information between steps associated with a recursive remove, but even with that kind of thing in place, unless we change how AbstractRemoveStepHandler works (likely breaking subclasses) at the time the child decides whether or not to require reload it's not going to know what the parents will decide.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7483) Credential store has configuration in "uri" attribute.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7483?page=com.atlassian.jira.plugin.... ]
Hynek Švábek commented on WFLY-7483:
------------------------------------
Thanks [~brian.stansberry] for the answer.
Parameters aren't fully defined because you can have your own custom implementation of CredentialStore and add there you own parameters to "URI"
> Credential store has configuration in "uri" attribute.
> ------------------------------------------------------
>
> Key: WFLY-7483
> URL: https://issues.jboss.org/browse/WFLY-7483
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Critical
>
> Credential store has configuration in "uri" attribute. All parameters are in one string. It can be confusing and there is risk of typo (e.g. delimiter typo)
> In my opinion the main intention for it is to have general solution for custom implementation.
> *Current state*
> {code}
> /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/keystore.jceks?store.password=pass123;create.storage=true")
> {code}
> *Suggestion for improvement:*
> Better solution to achieve this could be use a map.
> e.g. some like that:
> {code}
> /subsystem=elytron/credential-store=credStore:add(cs-map={store.password=pass123, create.storage=true, store.file=path/to/cred/file})
> {code}
> Now credential store name is in URI too, it can be get from resource name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7483) Credential store has configuration in "uri" attribute.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7483?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7483:
----------------------------------------
Is your cs-map a simple map or is it a complex attribute? That is are "store" and "create" fully defined fields of attribute cs-map, with fully defined child fields "password", "storage", "file"? Or are "store.password" etc arbitrary keys in a map?
Fully specified parameters have significant advantages over arbitrary ones and we should use those if at all possible. But if the map is just arbitrary key/value pairs, I don't have a strong preference for it over a string. If the uri is going to be useful in other contexts than WildFly management calls, so some users will learn the uri syntax, then using a different arbitrary format in WildFly management will be confusing.
> Credential store has configuration in "uri" attribute.
> ------------------------------------------------------
>
> Key: WFLY-7483
> URL: https://issues.jboss.org/browse/WFLY-7483
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Critical
>
> Credential store has configuration in "uri" attribute. All parameters are in one string. It can be confusing and there is risk of typo (e.g. delimiter typo)
> In my opinion the main intention for it is to have general solution for custom implementation.
> *Current state*
> {code}
> /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/keystore.jceks?store.password=pass123;create.storage=true")
> {code}
> *Suggestion for improvement:*
> Better solution to achieve this could be use a map.
> e.g. some like that:
> {code}
> /subsystem=elytron/credential-store=credStore:add(cs-map={store.password=pass123, create.storage=true, store.file=path/to/cred/file})
> {code}
> Now credential store name is in URI too, it can be get from resource name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7921) JGRP000225: failed unmarshalling buffer into return value: NPE (ASYM_ENCRYPT + TCP, during server startup)
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-7921?page=com.atlassian.jira.plugin.... ]
Michal Vinkler updated WFLY-7921:
---------------------------------
Description:
Scenario: failover clustering test with enabled "AUTH" and "ASYM_ENCRYPT" protocols + JGroups default stack set to *TCP*. This issue doesn't occur when using UDP stack.
Also, encrypt_entire_message needs to be set to *"false"*
{code:xml|title=TCP stack configuration}
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="MPING" socket-binding="jgroups-mping"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="ASYM_ENCRYPT">
<property name="encrypt_entire_message">false</property>
<property name="sym_keylength">128</property>
<property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
<property name="asym_keylength">512</property>
<property name="asym_algorithm">RSA</property>
</protocol>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="AUTH">
<property name="auth_class">org.jgroups.auth.MD5Token</property>
<property name="auth_value">jdgservercluster</property>
<property name="token_hash">MD5</property>
</protocol>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
{code}
During servers startup, after receiving a new cluster view, one of the servers usually logs this error message:
{code}
08:35:36,707 ERROR [org.jgroups.blocks.RequestCorrelator] (thread-1,ee,node2) JGRP000225: failed unmarshalling buffer into return value: java.lang.NullPointerException
at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:70)
at java.nio.ByteBuffer.wrap(ByteBuffer.java:373)
at org.jboss.as.clustering.infinispan.ChannelFactoryTransport$1.objectFromBuffer(ChannelFactoryTransport.java:81)
at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:419)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
at org.jgroups.JChannel.up(JChannel.java:738)
at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
at org.jgroups.stack.Protocol.up(Protocol.java:380)
at org.jgroups.protocols.FORK.up(FORK.java:114)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1037)
at org.jgroups.protocols.AUTH.up(AUTH.java:150)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
at org.jgroups.protocols.EncryptBase.handleEncryptedMessage(EncryptBase.java:242)
at org.jgroups.protocols.EncryptBase.handleUpMessage(EncryptBase.java:227)
at org.jgroups.protocols.EncryptBase.up(EncryptBase.java:150)
at org.jgroups.protocols.ASYM_ENCRYPT.up(ASYM_ENCRYPT.java:116)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
at org.jgroups.protocols.FD.up(FD.java:260)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
at org.jgroups.protocols.Discovery.up(Discovery.java:296)
at org.jgroups.protocols.MPING.up(MPING.java:178)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1873)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory$$Lambda$547/364315896.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
{code}
was:
Scenario: failover clustering test with enabled "AUTH" and "ASYM_ENCRYPT" protocols + JGroups default stack set to *TCP*. This issue doesn't occur when using UDP stack.
{code:xml|title=TCP stack configuration}
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="MPING" socket-binding="jgroups-mping"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="ASYM_ENCRYPT">
<property name="encrypt_entire_message">false</property>
<property name="sym_keylength">128</property>
<property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
<property name="asym_keylength">512</property>
<property name="asym_algorithm">RSA</property>
</protocol>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="AUTH">
<property name="auth_class">org.jgroups.auth.MD5Token</property>
<property name="auth_value">jdgservercluster</property>
<property name="token_hash">MD5</property>
</protocol>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
{code}
During servers startup, after receiving a new cluster view, one of the servers usually logs this error message:
{code}
08:35:36,707 ERROR [org.jgroups.blocks.RequestCorrelator] (thread-1,ee,node2) JGRP000225: failed unmarshalling buffer into return value: java.lang.NullPointerException
at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:70)
at java.nio.ByteBuffer.wrap(ByteBuffer.java:373)
at org.jboss.as.clustering.infinispan.ChannelFactoryTransport$1.objectFromBuffer(ChannelFactoryTransport.java:81)
at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:419)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
at org.jgroups.JChannel.up(JChannel.java:738)
at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
at org.jgroups.stack.Protocol.up(Protocol.java:380)
at org.jgroups.protocols.FORK.up(FORK.java:114)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1037)
at org.jgroups.protocols.AUTH.up(AUTH.java:150)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
at org.jgroups.protocols.EncryptBase.handleEncryptedMessage(EncryptBase.java:242)
at org.jgroups.protocols.EncryptBase.handleUpMessage(EncryptBase.java:227)
at org.jgroups.protocols.EncryptBase.up(EncryptBase.java:150)
at org.jgroups.protocols.ASYM_ENCRYPT.up(ASYM_ENCRYPT.java:116)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
at org.jgroups.protocols.FD.up(FD.java:260)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
at org.jgroups.protocols.Discovery.up(Discovery.java:296)
at org.jgroups.protocols.MPING.up(MPING.java:178)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1873)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory$$Lambda$547/364315896.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
{code}
> JGRP000225: failed unmarshalling buffer into return value: NPE (ASYM_ENCRYPT + TCP, during server startup)
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7921
> URL: https://issues.jboss.org/browse/WFLY-7921
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> Scenario: failover clustering test with enabled "AUTH" and "ASYM_ENCRYPT" protocols + JGroups default stack set to *TCP*. This issue doesn't occur when using UDP stack.
> Also, encrypt_entire_message needs to be set to *"false"*
> {code:xml|title=TCP stack configuration}
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="ASYM_ENCRYPT">
> <property name="encrypt_entire_message">false</property>
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> </protocol>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="AUTH">
> <property name="auth_class">org.jgroups.auth.MD5Token</property>
> <property name="auth_value">jdgservercluster</property>
> <property name="token_hash">MD5</property>
> </protocol>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> </stack>
> {code}
> During servers startup, after receiving a new cluster view, one of the servers usually logs this error message:
> {code}
> 08:35:36,707 ERROR [org.jgroups.blocks.RequestCorrelator] (thread-1,ee,node2) JGRP000225: failed unmarshalling buffer into return value: java.lang.NullPointerException
> at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:70)
> at java.nio.ByteBuffer.wrap(ByteBuffer.java:373)
> at org.jboss.as.clustering.infinispan.ChannelFactoryTransport$1.objectFromBuffer(ChannelFactoryTransport.java:81)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:419)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:380)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1037)
> at org.jgroups.protocols.AUTH.up(AUTH.java:150)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
> at org.jgroups.protocols.EncryptBase.handleEncryptedMessage(EncryptBase.java:242)
> at org.jgroups.protocols.EncryptBase.handleUpMessage(EncryptBase.java:227)
> at org.jgroups.protocols.EncryptBase.up(EncryptBase.java:150)
> at org.jgroups.protocols.ASYM_ENCRYPT.up(ASYM_ENCRYPT.java:116)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:260)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.MPING.up(MPING.java:178)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1873)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory$$Lambda$547/364315896.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months