[JBoss JIRA] (JGRP-2030) GMS: view_ack_collection_timeout delay when last 2 members leave concurrently
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2030?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2030:
--------------------------------
[~dan.berindei]: can I close this?
> GMS: view_ack_collection_timeout delay when last 2 members leave concurrently
> -----------------------------------------------------------------------------
>
> Key: JGRP-2030
> URL: https://issues.jboss.org/browse/JGRP-2030
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> When the coordinator ({{NodeE}}) leaves, it tries to install a new view on behalf of the new coordinator ({{NodeG}}, the last member).
> {noformat}
> 21:33:26,844 TRACE (ViewHandler,InitialClusterSizeTest-NodeE-42422:) [GMS] InitialClusterSizeTest-NodeE-42422: mcasting view [InitialClusterSizeTest-NodeG-30521|3] (1) [InitialClusterSizeTest-NodeG-30521] (1 mbrs)
> 21:33:26,844 TRACE (ViewHandler,InitialClusterSizeTest-NodeE-42422:) [TCP_NIO2] InitialClusterSizeTest-NodeE-42422: sending msg to null, src=InitialClusterSizeTest-NodeE-42422, headers are GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster_name=ISPN]
> {noformat}
> The message is actually sent later by the bundler, but {{NodeG}} is also sending its {{LEAVE_REQ}} message at the same time. Both nodes try to create a connection to each other, and only {{NodeG}} succeeds:
> {noformat}
> 21:33:26,844 TRACE (ForkThread-2,InitialClusterSizeTest:) [TCP_NIO2] InitialClusterSizeTest-NodeG-30521: sending msg to InitialClusterSizeTest-NodeE-42422, src=InitialClusterSizeTest-NodeG-30521, headers are GMS: GmsHeader[LEAVE_REQ]: mbr=InitialClusterSizeTest-NodeG-30521, UNICAST3: DATA, seqno=1, conn_id=1, first, TP: [cluster_name=ISPN]
> 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeG-30521:) [TCP_NIO2] InitialClusterSizeTest-NodeG-30521: sending 1 msgs (83 bytes (0.27% of max_bundle_size) to 1 dests(s): [ISPN:InitialClusterSizeTest-NodeE-42422]
> 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeE-42422:) [TCP_NIO2] InitialClusterSizeTest-NodeE-42422: sending 1 msgs (91 bytes (0.29% of max_bundle_size) to 1 dests(s): [ISPN]
> 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeG-30521:) [TCP_NIO2] dest=127.0.0.1:7900 (86 bytes)
> 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeE-42422:) [TCP_NIO2] dest=127.0.0.1:7920 (94 bytes)
> 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeE-42422:) [TCP_NIO2] 127.0.0.1:7900: connecting to 127.0.0.1:7920
> 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeG-30521:) [TCP_NIO2] 127.0.0.1:7920: connecting to 127.0.0.1:7900
> 21:33:26,866 TRACE (NioConnection.Reader [null],InitialClusterSizeTest-NodeG-30521:) [TCP_NIO2] 127.0.0.1:7920: rejected connection from 127.0.0.1:7900 (connection existed and my address won as it's higher)
> 21:33:26,867 TRACE (OOB-1,InitialClusterSizeTest-NodeE-42422:) [TCP_NIO2] InitialClusterSizeTest-NodeE-42422: received [dst: InitialClusterSizeTest-NodeE-42422, src: InitialClusterSizeTest-NodeG-30521 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[LEAVE_REQ]: mbr=InitialClusterSizeTest-NodeG-30521, UNICAST3: DATA, seqno=1, conn_id=1, first, TP: [cluster_name=ISPN]
> {noformat}
> I'm guessing {{NodeE}} would need a {{STABLE}} round in order to retransmit the {{VIEW}} message, but I'm not sure if the stable round would work, since it already (partially?) installed the new view with {{NodeG}} as the only member. However, I think it should be possible for {{NodeE}} to remove {{NodeG}} from it's {{AckCollector}} once it receives its {{LEAVE_REQ}}, and stop blocking.
> This is a minor annoyance a few the Infinispan tests - most of them shut down the nodes serially, so they don't see this delay.
> The question is whether the concurrent connection setup can have an impact for other messages as well - e.g. during startup, when there aren't a lot of messages being sent around to trigger retransmission. Could the node that failed to open its connection retry immediately on the connection opened by the other node?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1799) Property separator not appended after argument value if argument completer uses non-zero offset
by Bartosz Spyrko-Śmietanko (JIRA)
Bartosz Spyrko-Śmietanko created WFCORE-1799:
------------------------------------------------
Summary: Property separator not appended after argument value if argument completer uses non-zero offset
Key: WFCORE-1799
URL: https://issues.jboss.org/browse/WFCORE-1799
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 3.0.0.Alpha7
Reporter: Bartosz Spyrko-Śmietanko
Assignee: Bartosz Spyrko-Śmietanko
Priority: Minor
For example:
module add --name=foo --dependencies=sun.scripting ==> space character is added at the end.
module add --name=foo --dependencies=sun.scripting,sun.jdk ==> Nothing happens, no space character added.
deployment-overlay add --name=foo --contents=foo=/some/file<TAB> ==> Nothing happens, no space character added.
This seems to be caused by a condition in [OperationRequestCompleter|https://github.com/wildfly/wildfly-core/blob/bc...] - if a suggested value is the same as current user input, ORC replaces the suggestion with a separator.
This only works if the offset returned by argument completer is 0 - if the completer provides only part of the value, this condition will never be triggered.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1785) Extension remove is not cleaning out provided capabilities
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1785:
-------------------------------------
Sent PR that properly implements removal of MRR so now we do recursive delete of all sub resources.
which also fixes this problem.
> Extension remove is not cleaning out provided capabilities
> ----------------------------------------------------------
>
> Key: WFCORE-1785
> URL: https://issues.jboss.org/browse/WFCORE-1785
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha7
> Reporter: Jan Tymel
> Assignee: Tomaz Cerar
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha8
>
>
> It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly.
> Actual result:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.",
> "rolled-back" => true
> }
> {code}
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518)
> at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669)
> at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368)
> at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226)
> at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83)
> at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226)
> at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694)
> at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
> at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 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}
> Expected result:
> It is possible to add Elytron subsystem after its removal.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1793) add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1793?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet commented on WFCORE-1793:
-------------------------------------------
path is not a valid parameter, fixing the operation definition
> add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1793
> URL: https://issues.jboss.org/browse/WFCORE-1793
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
>
> Upon overwriting content in managed exploded deployments on wildfly-core, the following errors are produced:
> {{CLI}}
> {code}[standalone@localhost:9990 /] deploy /home/mjurc/testing/eap7-204/jboss-kitchensink-ear.ear
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=true)
> {
> "outcome" => "failed",
> "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=false)
> {
> "outcome" => "failed",
> "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}])
> {
> "outcome" => "failed",
> "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment",
> "rolled-back" => true
> }{code}
> {{Server}}
> {code}09:41:36,029 WARN [org.jboss.as.repository] (management-handler-thread - 5) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content7797527203290314566/content/test.txt
> 09:45:27,505 WARN [org.jboss.as.repository] (management-handler-thread - 12) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content721393778736298367/content/test.txt
> 09:45:36,352 WARN [org.jboss.as.repository] (management-handler-thread - 10) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content344811471223714239/content/test.txt{code}
> This issue does not seem to arise when the content is passed to the server by input stream index.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-627:
--------------------------------
Darran: "need a bit more of a discussion here on that one next week" => postponed
> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
> Key: ELY-627
> URL: https://issues.jboss.org/browse/ELY-627
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.1.0.Beta8
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
>
> {noformat}
> "protocols" => {
> "type" => LIST,
> "description" => "The enabled protocols.",
> "expressions-allowed" => true,
> "nillable" => false,
> "allowed" => [
> "SSLv2",
> "SSLv3",
> "TLSv1",
> "TLSv1_1",
> "TLSv1_2",
> "TLSv1_3"
> ],
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java.
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN...
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months