[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2227:
--------------------------------
OK, the reason was that {{AUTH.auth_coord}} has to be set to {{false}} (default: {{true}}), or else the joiner would discard the coord's join response (which carried the join rejection).
However, as the signature of {{AUTH.setAuthCoord()}} changed from returning {{void}} to {{AUTH}}, the setter was not recognized as such anymore and the setting of the attribute {{auth_coord}} failed. I changed this and with {{auth_coord=false}}, I do get the following exception on the joiner (in master):
{noformat}
java.lang.Exception: connecting to channel draw failed
at org.jgroups.JChannel._connect(JChannel.java:904)
at org.jgroups.JChannel.connect(JChannel.java:393)
at org.jgroups.JChannel.connect(JChannel.java:384)
at org.jgroups.demos.Draw.go(Draw.java:197)
at org.jgroups.demos.Draw.main(Draw.java:160)
Caused by: java.lang.SecurityException: authentication failed
at org.jgroups.protocols.pbcast.ClientGmsImpl.isJoinResponseValid(ClientGmsImpl.java:183)
at org.jgroups.protocols.pbcast.ClientGmsImpl.installViewIfValidJoinRsp(ClientGmsImpl.java:149)
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:107)
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1063)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:901)
at org.jgroups.JChannel.down(JChannel.java:668)
at org.jgroups.JChannel._connect(JChannel.java:897)
{noformat}
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.8
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9456) High non heap memory consumption
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9456?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFLY-9456:
------------------------------
Need Info from: Klaus Erber
> High non heap memory consumption
> --------------------------------
>
> Key: WFLY-9456
> URL: https://issues.jboss.org/browse/WFLY-9456
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 11.0.0.CR1, 11.0.0.Final
> Environment: CentOS 7 on Google compute engine VM
> openjdk version "1.8.0_144"
> OpenJDK Runtime Environment (build 1.8.0_144-b01)
> OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
> Reporter: Klaus Erber
> Assignee: David Lloyd
> Attachments: wf10-nmt.txt, wf11-nmt.txt
>
>
> After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
> Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
> Her are the output auf ps aux:
> wf11
> ke4 1652 14.0 22.1 2863404 *801620* pts/3 Sl+ 14:01 0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> wf10
> ke4 1836 42.1 5.7 2687744 *209204* pts/2 Sl+ 14:02 0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
> The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9470) Cannot batch-drop sar extension and subsystem
by Marcel Šebek (JIRA)
Marcel Šebek created WFLY-9470:
----------------------------------
Summary: Cannot batch-drop sar extension and subsystem
Key: WFLY-9470
URL: https://issues.jboss.org/browse/WFLY-9470
Project: WildFly
Issue Type: Bug
Affects Versions: 11.0.0.Final
Environment: OpenJDK 8, Linux, 64 bit.
Reporter: Marcel Šebek
Assignee: Jason Greene
Dropping SAR subsystem and SAR extension in a batch results in
```
15:36:09,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("remove") failed - address: ([("subsystem" => "sar")]): java.lang.NullPointerException
at org.jboss.as.controller.CapabilityRegistry.getCapabilitiesForAddress(CapabilityRegistry.java:469)
at org.jboss.as.controller.CapabilityRegistry.capabilityReloadRequired(CapabilityRegistry.java:446)
at org.jboss.as.controller.AbstractOperationContext.reloadRequired(AbstractOperationContext.java:1122)
at org.jboss.as.controller.ReloadRequiredRemoveStepHandler.performRuntime(ReloadRequiredRemoveStepHandler.java:56)
at org.jboss.as.controller.AbstractRemoveStepHandler$1.execute(AbstractRemoveStepHandler.java:82)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
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:287)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
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:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
15:36:09,807 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0190: Step handler org.jboss.as.controller.extension.ExtensionRemoveHandler@3ca42854 for operation remove at address [("extension" => "org.jboss.as.sar")] failed handling operation rollback -- java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.sar-deployment' is already registered in context 'global'.: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.sar-deployment' is already registered in context 'global'.
at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:572)
at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:566)
at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:684)
at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:362)
at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:112)
at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:231)
at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:706)
at org.jboss.as.service.SarExtension.initialize(SarExtension.java:93)
at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
at org.jboss.as.controller.extension.ExtensionRemoveHandler$1.handleRollback(ExtensionRemoveHandler.java:81)
at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1526)
at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1498)
at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1480)
at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1437)
at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1420)
at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1284)
at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:857)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:739)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
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:287)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
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:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
```
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9458) Support expressions for "site" attribute inside "backup" element in infinispan subsystem
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/WFLY-9458?page=com.atlassian.jira.plugin.... ]
Marek Posolda resolved WFLY-9458.
---------------------------------
Resolution: Duplicate Issue
Closing as it's duplicate of already existing WFLY-7871
> Support expressions for "site" attribute inside "backup" element in infinispan subsystem
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-9458
> URL: https://issues.jboss.org/browse/WFLY-9458
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Marek Posolda
> Assignee: Paul Ferraro
> Priority: Minor
>
> Assume I have this in standalone.xml in infinispan subsystem:
> {code}
> <distributed-cache name="foo">
> <backups>
> <backup site="${remote.site}" failure-policy="${backup.policy}" strategy="SYNC" enabled="true"/>
> </backups>
> </distributed-cache>
> {code}
> and I run server with:
> {code}
> ./standalone.sh -Dremote.site=mysite -Dbackup.policy=FAIL
> {code}
> I can see that "backup.policy" expression is correctly resolved, but "remote.site" is not. Indeed BackupResourceDefinition class, enum "Attribute" doesn't contain SITE attribute.
> It will be nice if expressions are supported for "site" attribute too, so that I can have single ZIP distribution and use it for simulate testing with more sites and just use different system properties to simulate different site.
> BTV. JGroups subsystem already supports the expressions inside "relay" element.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9458) Support expressions for "site" attribute inside "backup" element in infinispan subsystem
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/WFLY-9458?page=com.atlassian.jira.plugin.... ]
Marek Posolda edited comment on WFLY-9458 at 10/24/17 8:55 AM:
---------------------------------------------------------------
Closing as it's duplicate of already existing WFLY-7871 . Thanks [~rhusar] for pointing that.
was (Author: mposolda):
Closing as it's duplicate of already existing WFLY-7871
> Support expressions for "site" attribute inside "backup" element in infinispan subsystem
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-9458
> URL: https://issues.jboss.org/browse/WFLY-9458
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Marek Posolda
> Assignee: Paul Ferraro
> Priority: Minor
>
> Assume I have this in standalone.xml in infinispan subsystem:
> {code}
> <distributed-cache name="foo">
> <backups>
> <backup site="${remote.site}" failure-policy="${backup.policy}" strategy="SYNC" enabled="true"/>
> </backups>
> </distributed-cache>
> {code}
> and I run server with:
> {code}
> ./standalone.sh -Dremote.site=mysite -Dbackup.policy=FAIL
> {code}
> I can see that "backup.policy" expression is correctly resolved, but "remote.site" is not. Indeed BackupResourceDefinition class, enum "Attribute" doesn't contain SITE attribute.
> It will be nice if expressions are supported for "site" attribute too, so that I can have single ZIP distribution and use it for simulate testing with more sites and just use different system properties to simulate different site.
> BTV. JGroups subsystem already supports the expressions inside "relay" element.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2224) Multiple discovery protocols
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/JGRP-2224?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on JGRP-2224:
-------------------------------------------
Awesome! That sounds good. Thanks a lot for looking into it Bela!
> Multiple discovery protocols
> ----------------------------
>
> Key: JGRP-2224
> URL: https://issues.jboss.org/browse/JGRP-2224
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.8
>
>
> Allow for multiple discovery protocols. This would allow us to use a single configuration which includes discovery protocols for multiple cloud providers.
> The discovery protocols could be queried sequentially (return on result), or in parallel.
> Investigate whether we need a super discovery protocol which instantiates the individual protocols, or whether each protocol should be changed e.g. to forward events down the stack.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2224) Multiple discovery protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2224?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2224:
--------------------------------
The order is the order of listing the protocols _below_ {{MULTI_PING}}, e.g. in the above case, {{FILE_PING}} will be invoked first.
However, if you set {{async_discovety=true}}, then it doesn't matter, as each protocol will be invoked in a separate thread.
Re merging: the {{Responses}} object takes care of that: a response from a coordinator overwrites existing entries, and otherwise responses from thye same member are only counted once. All elements are of type {{PingData}} and as such are comparable (by sender address).
The discovery protocol typically returns when at least 1 coordinator response has been received, otherwise it waits for the timeout to kick in.
> Multiple discovery protocols
> ----------------------------
>
> Key: JGRP-2224
> URL: https://issues.jboss.org/browse/JGRP-2224
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.8
>
>
> Allow for multiple discovery protocols. This would allow us to use a single configuration which includes discovery protocols for multiple cloud providers.
> The discovery protocols could be queried sequentially (return on result), or in parallel.
> Investigate whether we need a super discovery protocol which instantiates the individual protocols, or whether each protocol should be changed e.g. to forward events down the stack.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months