[JBoss JIRA] (ELY-20) Where does OTP fit into realms?
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-20?page=com.atlassian.jira.plugin.sys... ]
Jan Kalina updated ELY-20:
--------------------------
Description:
Will investigate further once we have a pure LDAP impl in.
We could have an architecture where we have an LDAP server that is then referenced by an *OTP server* or we could have the two somehow combined into one.
There are also requirements related to *marking a token as used* or *token invalidation after too many bad attempts* - this may be handled within the OTP server but for stronger authentication mechanisms may need to be more involved otherwise this becomes another case of falling back to PLAIN / BASIC auth.
was:
Will investigate further once we have a pure LDAP impl in.
We could have an architecture where we have an LDAP server that is then referenced by an OTP server or we could have the two somehow combined into one.
There are also requirements related to marking a token as used or token invalidation after too many bad attempts - this may be handled within the OTP server but for stronger authentication mechanisms may need to be more involved otherwise this becomes another case of falling back to PLAIN / BASIC auth.
> Where does OTP fit into realms?
> -------------------------------
>
> Key: ELY-20
> URL: https://issues.jboss.org/browse/ELY-20
> Project: WildFly Elytron
> Issue Type: Sub-task
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 1.1.0.CR1
>
>
> Will investigate further once we have a pure LDAP impl in.
> We could have an architecture where we have an LDAP server that is then referenced by an *OTP server* or we could have the two somehow combined into one.
> There are also requirements related to *marking a token as used* or *token invalidation after too many bad attempts* - this may be handled within the OTP server but for stronger authentication mechanisms may need to be more involved otherwise this becomes another case of falling back to PLAIN / BASIC auth.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6781:
--------------------------------------
I understood it as it power offing of node 2 somehow negatively affected networking on node 2. The point was that the problem is on OS or VM level.
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2043:
--------------------------------
This solution won't be available in the 3.6 branch as JDK 8 is not the baseline there, and lambdas are not available...
The benchmark showed that using constructors or method handles doesn't yield better performance.
> Improve performance of Message#readHeader
> -----------------------------------------
>
> Key: JGRP-2043
> URL: https://issues.jboss.org/browse/JGRP-2043
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> A CPU hot spot highlighed by profiling via JFR:
> {noformat}Stack Trace Sample Count Percentage(%)
> java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392
> java.lang.Class.newInstance() 71 2.392
> org.jgroups.Message.readHeader(DataInput) 71 2.392
> {noformat}
> I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into.
> It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2043 at 7/13/16 6:09 AM:
---------------------------------------------------------
Turns out this is useless: if a {{MethodHandle}} is not _static_, apparently it cannot be optimized: if we store handles in a map (keyed by magic ID), then performance is about the same as using a constructor, or reflection.
The only fast way I've found so far is to create a method handle _indirectly_ via a lambda, ie.:
{code:java}
Supplier<? extends Header> supplier;
Header hdr=supplier.get();
{code}
This requires all headers to implement a Constructable interface which returns a supplier.
[1] https://github.com/belaban/PerfTests/blob/master/src/main/java/org/perfte...
was (Author: belaban):
Turns out this is useless: if a {{MethodHandle}} is not _static_, apparently it cannot be optimized: if we store handles in a map (keyed by magic ID), then performance is about the same as using a constructor, or reflection.
The only fast way I've found so far is to create a method handle _indirectly_ via a lambda, ie.:
{code:java}
Supplier<? extends Header> supplier;
Header hdr=supplier.get();
{code}
This requires all headers to implement a Creationable interface which returns a supplier.
[1] https://github.com/belaban/PerfTests/blob/master/src/main/java/org/perfte...
> Improve performance of Message#readHeader
> -----------------------------------------
>
> Key: JGRP-2043
> URL: https://issues.jboss.org/browse/JGRP-2043
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> A CPU hot spot highlighed by profiling via JFR:
> {noformat}Stack Trace Sample Count Percentage(%)
> java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392
> java.lang.Class.newInstance() 71 2.392
> org.jgroups.Message.readHeader(DataInput) 71 2.392
> {noformat}
> I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into.
> It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JBJCA-1321) Statement.cancel() is not invoked until the statement is completed
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin... ]
Lin Gao resolved JBJCA-1321.
----------------------------
Resolution: Done
> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
> Key: JBJCA-1321
> URL: https://issues.jboss.org/browse/JBJCA-1321
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
> Reporter: lorenzo benvenuti
> Assignee: Lin Gao
> Priority: Critical
> Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
> {
> if (doLocking)
> lock();
> try
> {
> /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6781:
----------------------------------------
Hi Miroslav,
The issue is still not solved. To answer to your question:
"Maybe it would be worth to check node1 networking after power offing node2. Did it do something bad with Windows networking on node 1?"
Yes, it did bad on Node1 when Node2 is powered off. The JMS message on Node1 was not getting processed.
Thanks,
Preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1650) Subsystem - connector resource description and schema file claim that more socket bindings can be used
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1650?page=com.atlassian.jira.plugi... ]
Chao Wang moved WFLY-6832 to WFCORE-1650:
-----------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1650 (was: WFLY-6832)
Component/s: Remoting
(was: Remoting)
Affects Version/s: 2.2.0.CR7
(was: 10.0.0.Final)
> Subsystem - connector resource description and schema file claim that more socket bindings can be used
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1650
> URL: https://issues.jboss.org/browse/WFCORE-1650
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 2.2.0.CR7
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Since the schema for Remoting subsystem says that multiple socket bindings should be allowed on a connector, I'm trying to create a connector like that and I couldn't get it to work.
> I assume the correct syntax should be the one with {{[rjanik-sb1,rjanik-sb2]}} since the socket bindings are defined as {{xs:list}} in the schema file. Here's what I tried:
> {code}
> [standalone@localhost:9990 /] /socket-binding-group=standard-sockets/socket-binding=rjanik-sb1:add(interface=public)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /socket-binding-group=standard-sockets/socket-binding=rjanik-sb2:add(interface=public)
> {"outcome" => "success"}
> standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="rjanik-sb1 rjanik-sb2")
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: Invalid name character at offset 45",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="rjanik-sb1, rjanik-sb2")
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: Invalid name character at offset 46",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="rjanik-sb1,rjanik-sb2")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.newcon is missing [org.wildfly.network.socket-binding.rjanik-sb1,rjanik-sb2]"]},
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="org.wildfly.network.socket-binding.rjanik-sb1,org.wildfly.network.socket-binding.rjanik-sb2")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.newcon is missing [org.wildfly.network.socket-binding.org.wildfly.network.socket-binding.rjanik-sb1,org.wildfly.network.socket-binding.rjanik-sb2]"]},
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="rjanik-sb1,org.wildfly.network.socket-binding.rjanik-sb2")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.newcon is missing [org.wildfly.network.socket-binding.rjanik-sb1,org.wildfly.network.socket-binding.rjanik-sb2]"]},
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding=[rjanik-sb1,rjanik-sb2])
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0097: Wrong type for socket-binding. Expected [STRING] but was LIST",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="[rjanik-sb1,rjanik-sb2]")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.newcon is missing [org.wildfly.network.socket-binding.[rjanik-sb1,rjanik-sb2]]"]},
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="[rjanik-sb1],[rjanik-sb2]")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.newcon is missing [org.wildfly.network.socket-binding.[rjanik-sb1],[rjanik-sb2]]"]},
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding=["rjanik-sb1","rjanik-sb2"])
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0097: Wrong type for socket-binding. Expected [STRING] but was LIST",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6832) Subsystem - connector resource description and schema file claim that more socket bindings can be used
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6832?page=com.atlassian.jira.plugin.... ]
Chao Wang moved JBEAP-5191 to WFLY-6832:
----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6832 (was: JBEAP-5191)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Remoting
(was: CLI)
(was: Remoting)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.GA)
> Subsystem - connector resource description and schema file claim that more socket bindings can be used
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6832
> URL: https://issues.jboss.org/browse/WFLY-6832
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Since the schema for Remoting subsystem says that multiple socket bindings should be allowed on a connector, I'm trying to create a connector like that and I couldn't get it to work.
> I assume the correct syntax should be the one with {{[rjanik-sb1,rjanik-sb2]}} since the socket bindings are defined as {{xs:list}} in the schema file. Here's what I tried:
> {code}
> [standalone@localhost:9990 /] /socket-binding-group=standard-sockets/socket-binding=rjanik-sb1:add(interface=public)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /socket-binding-group=standard-sockets/socket-binding=rjanik-sb2:add(interface=public)
> {"outcome" => "success"}
> standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="rjanik-sb1 rjanik-sb2")
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: Invalid name character at offset 45",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="rjanik-sb1, rjanik-sb2")
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: Invalid name character at offset 46",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="rjanik-sb1,rjanik-sb2")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.newcon is missing [org.wildfly.network.socket-binding.rjanik-sb1,rjanik-sb2]"]},
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="org.wildfly.network.socket-binding.rjanik-sb1,org.wildfly.network.socket-binding.rjanik-sb2")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.newcon is missing [org.wildfly.network.socket-binding.org.wildfly.network.socket-binding.rjanik-sb1,org.wildfly.network.socket-binding.rjanik-sb2]"]},
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="rjanik-sb1,org.wildfly.network.socket-binding.rjanik-sb2")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.newcon is missing [org.wildfly.network.socket-binding.rjanik-sb1,org.wildfly.network.socket-binding.rjanik-sb2]"]},
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding=[rjanik-sb1,rjanik-sb2])
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0097: Wrong type for socket-binding. Expected [STRING] but was LIST",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="[rjanik-sb1,rjanik-sb2]")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.newcon is missing [org.wildfly.network.socket-binding.[rjanik-sb1,rjanik-sb2]]"]},
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding="[rjanik-sb1],[rjanik-sb2]")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.newcon is missing [org.wildfly.network.socket-binding.[rjanik-sb1],[rjanik-sb2]]"]},
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=remoting/connector=newcon:add(socket-binding=["rjanik-sb1","rjanik-sb2"])
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0097: Wrong type for socket-binding. Expected [STRING] but was LIST",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6781:
--------------------------------------
Did you manage to solve the problem? Could you try another network configuration for VMs? I believe this jira can be closed then.
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1647) Default app-name value of Syslog handler in Audit Logging violates specification
by Jan Tymel (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1647?page=com.atlassian.jira.plugi... ]
Jan Tymel commented on WFCORE-1647:
-----------------------------------
Specification says {{APP-NAME = NILVALUE / 1*48PRINTUSASCII}}, i.e. {{-}} or {{string with (at maximum) 48 chars}}. These chars can be only printable excluding space character (and DEL) {{PRINTUSASCII = %d33-126}}, space character has ASCII code {{32}} (DEL {{127}}).
> Default app-name value of Syslog handler in Audit Logging violates specification
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1647
> URL: https://issues.jboss.org/browse/WFCORE-1647
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha3
> Reporter: Jan Tymel
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha4, 2.2.0.CR8
>
>
> According to syslog specification[1] {{app-name}} cannot contain space character (" "). However, the default value in WildFly Core 3.0.0.Alpha3 is {{WildFly Core}}. This results in the syslog server is not able to capture Process ID from which the message was sent.
> E.g. following piece of information is captured {{WildFly[Core] (...)}} instead of {{WildFlyCore[795]}}
> Suggestions for improvement:
> Change default value {{WildFly Core}} to one without space character.
> Also please consider addition of check whether {{app-name}} contains space character.
> [1] https://tools.ietf.org/html/rfc5424#page-8
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months