[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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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 12:47 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 Creationable 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 onyl fast way I found so far is to create a methd 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)
9 years, 9 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:
--------------------------------
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 onyl fast way I found so far is to create a methd 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)
9 years, 9 months
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1649:
-------------------------------------
Maybe one option would be to go on with implementing "dynamic transformers registration" using service loader.
I have some prototype impl somewhere for subsystems work, but shouldn't be much more work to do the same for kernel transformers.
This would allow us to register transformers separately from kernel itself.
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 3.0.0.Beta1
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1649:
----------------------------------------
Assignee: Brian Stansberry
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 3.0.0.Beta1
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months