[JBoss JIRA] (LOGMGR-263) Static Logger Lookup is much slower as with JDK 8
by Andreas Liebscher (Jira)
[ https://issues.jboss.org/browse/LOGMGR-263?page=com.atlassian.jira.plugin... ]
Andreas Liebscher updated LOGMGR-263:
-------------------------------------
Attachment: grafik1570016791285.png
> Static Logger Lookup is much slower as with JDK 8
> -------------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.jboss.org/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `static Logger log = LoggerFactory.getLogger(StatusChangeValidatorFactory.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we removed `static` from some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the removed `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (LOGMGR-263) Static Logger Lookup is much slower as with JDK 8
by Andreas Liebscher (Jira)
[ https://issues.jboss.org/browse/LOGMGR-263?page=com.atlassian.jira.plugin... ]
Andreas Liebscher updated LOGMGR-263:
-------------------------------------
Attachment: grafik1570016303722 (1).png
> Static Logger Lookup is much slower as with JDK 8
> -------------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.jboss.org/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: grafik1570016303722 (1).png, grafik1570016303722.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `static Logger log = LoggerFactory.getLogger(StatusChangeValidatorFactory.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we removed `static` from some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the removed `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (LOGMGR-263) Static Logger Lookup is much slower as with JDK 8
by Andreas Liebscher (Jira)
[ https://issues.jboss.org/browse/LOGMGR-263?page=com.atlassian.jira.plugin... ]
Andreas Liebscher updated LOGMGR-263:
-------------------------------------
Attachment: grafik1570016303722.png
> Static Logger Lookup is much slower as with JDK 8
> -------------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.jboss.org/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: grafik1570016303722 (1).png, grafik1570016303722.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `static Logger log = LoggerFactory.getLogger(StatusChangeValidatorFactory.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we removed `static` from some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the removed `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (LOGMGR-263) Static Logger Lookup is much slower as with JDK 8
by Andreas Liebscher (Jira)
Andreas Liebscher created LOGMGR-263:
----------------------------------------
Summary: Static Logger Lookup is much slower as with JDK 8
Key: LOGMGR-263
URL: https://issues.jboss.org/browse/LOGMGR-263
Project: JBoss Log Manager
Issue Type: Bug
Environment: WildFly 17, OpenJDK 11
Reporter: Andreas Liebscher
During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `static Logger log = LoggerFactory.getLogger(StatusChangeValidatorFactory.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we removed `static` from some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the removed `static` keyword.
Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12845) Upgrade JGroups to 4.1.9.Final
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-12845?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-12845:
---------------------------------------
Here is the compilation problem (removed static field):
{noformat}
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /Users/rhusar/git/wildfly/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/AbstractProtocolConfigurationServiceConfigurator.java:[118,216] cannot find symbol
symbol: variable protocol_prefix
location: class org.jgroups.conf.ProtocolConfiguration
[ERROR] /Users/rhusar/git/wildfly/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/AbstractProtocolConfigurationServiceConfigurator.java:[119,100] cannot find symbol
symbol: variable protocol_prefix
location: class org.jgroups.conf.ProtocolConfiguration
[ERROR] /Users/rhusar/git/wildfly/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ProtocolRegistration.java:[106,87] cannot find symbol
symbol: variable protocol_prefix
location: class org.jgroups.conf.ProtocolConfiguration
[ERROR] /Users/rhusar/git/wildfly/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/GenericProtocolResourceDefinition.java:[43,110] cannot find symbol
symbol: variable protocol_prefix
location: class org.jgroups.conf.ProtocolConfiguration
[ERROR] /Users/rhusar/git/wildfly/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ProtocolDefaultsServiceConfigurator.java:[108,99] cannot find symbol
symbol: variable protocol_prefix
location: class org.jgroups.conf.ProtocolConfiguration
[ERROR] /Users/rhusar/git/wildfly/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ChannelRuntimeResourceRegistration.java:[142,195] cannot find symbol
symbol: variable protocol_prefix
location: class org.jgroups.conf.ProtocolConfiguration
[ERROR] /Users/rhusar/git/wildfly/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ChannelRuntimeResourceRegistration.java:[143,80] cannot find symbol
symbol: variable protocol_prefix
location: class org.jgroups.conf.ProtocolConfiguration
[INFO] 7 errors
{noformat}
> Upgrade JGroups to 4.1.9.Final
> ------------------------------
>
> Key: WFLY-12845
> URL: https://issues.jboss.org/browse/WFLY-12845
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Clustering
> Affects Versions: 18.0.1.Final
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Major
>
> Just a tracker for now.
> Changelog
> https://issues.jboss.org/projects/JGRP/versions/12343163
> The fix for JGRP-2409 has caused compilation failure thus updating the https://github.com/wildfly-clustering/wildfly/tree/jgroups-master branch with the fix from which PR will be opened.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-6747) messaging subsystem bridge fails on differents Ip orders
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-6747?page=com.atlassian.jira.plugin.... ]
Radoslav Husar closed WFLY-6747.
--------------------------------
Resolution: Out of Date
> messaging subsystem bridge fails on differents Ip orders
> --------------------------------------------------------
>
> Key: WFLY-6747
> URL: https://issues.jboss.org/browse/WFLY-6747
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0.Final domain mode. 2 Hosts each one with one server, one contains also the domain controller. Verified on Windows and on Linux (AWS machines).
> Reporter: Lorenzo Pirazzini
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> While trying to setup a clustered environment with Wildfly 8.2.0.Final I needed a shared topic between servers (I have two Linux machines on AWS).
> Everything works fine (domain creation, datasources/persistence unit, infinispan shared caches and Wildfly Console) except for HornetQ messaging subsystem.
> I can't use discovery because I don't have a multicast address, so I defined a *domain.xml* like this:
> <subsystem xmlns="urn:jboss:domain:messaging:2.0">
> <hornetq-server>
> <cluster-password>myPassword</cluster-password>
> <backup>false</backup>
> <shared-store>false</shared-store>
> <journal-file-size>102400</journal-file-size>
> <connectors>
> <http-connector name="http-connector" socket-binding="http">
> <param key="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> <http-connector name="http-connector-throughput" socket-binding="http">
> <param key="http-upgrade-endpoint" value="http-acceptor-throughput"/>
> <param key="batch-delay" value="50"/>
> </http-connector>
> <http-connector name="cnode1" socket-binding="node1">
> <param key="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> <http-connector name="cnode2" socket-binding="node2">
> <param key="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> <in-vm-connector name="in-vm" server-id="0"/>
> </connectors>
> <acceptors>
> <http-acceptor http-listener="default" name="http-acceptor"/>
> <http-acceptor http-listener="default" name="http-acceptor-throughput">
> <param key="batch-delay" value="50"/>
> <param key="direct-deliver" value="false"/>
> </http-acceptor>
> <in-vm-acceptor name="in-vm" server-id="0"/>
> </acceptors>
> <cluster-connections>
> <cluster-connection name="my-cluster">
> <address>jms</address>
> <connector-ref>http-connector</connector-ref>
> <static-connectors>
> <connector-ref>
> cnode1
> </connector-ref>
> <connector-ref>
> cnode2
> </connector-ref>
> </static-connectors>
> </cluster-connection>
> </cluster-connections>
> <security-settings>
> <security-setting match="#">
> <permission type="send" roles="guest"/>
> <permission type="consume" roles="guest"/>
> <permission type="createNonDurableQueue" roles="guest"/>
> <permission type="deleteNonDurableQueue" roles="guest"/>
> </security-setting>
> </security-settings>
> <address-settings>
> <address-setting match="#">
> <dead-letter-address>jms.queue.DLQ</dead-letter-address>
> <expiry-address>jms.queue.ExpiryQueue</expiry-address>
> <max-size-bytes>10485760</max-size-bytes>
> <page-size-bytes>2097152</page-size-bytes>
> <message-counter-history-day-limit>10</message-counter-history-day-limit>
> <redistribution-delay>1000</redistribution-delay>
> </address-setting>
> </address-settings>
> <jms-connection-factories>
> <connection-factory name="InVmConnectionFactory">
> <connectors>
> <connector-ref connector-name="in-vm"/>
> </connectors>
> <entries>
> <entry name="java:/ConnectionFactory"/>
> </entries>
> </connection-factory>
> <connection-factory name="RemoteConnectionFactory">
> <connectors>
> <connector-ref connector-name="http-connector"/>
> </connectors>
> <entries>
> <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
> </entries>
> <ha>true</ha>
> <block-on-acknowledge>true</block-on-acknowledge>
> <reconnect-attempts>-1</reconnect-attempts>
> </connection-factory>
> <pooled-connection-factory name="hornetq-ra">
> <transaction mode="xa"/>
> <connectors>
> <connector-ref connector-name="in-vm"/>
> </connectors>
> <entries>
> <entry name="java:/JmsXA"/>
> <entry name="java:jboss/DefaultJMSConnectionFactory"/>
> </entries>
> </pooled-connection-factory>
> </jms-connection-factories>
> <jms-destinations>
> ...
> <jms-topic name="MyTopic">
> <entry name="java:/jms/topic/MyTopic"/>
> </jms-topic>
> ...
> </jms-destinations>
> </hornetq-server>
> </subsystem>
> ...
> <socket-binding-group name="full-ha-sockets" default-interface="public">
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="jacorb" interface="unsecure" port="3528"/>
> <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
> <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
> <socket-binding name="jgroups-tcp" port="7600"/>
> <socket-binding name="jgroups-tcp-fd" port="57600"/>
> <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
> <socket-binding name="jgroups-udp-fd" port="54200"/>
> <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> <outbound-socket-binding name="node1">
> <remote-destination host="IP-A" port="8080"/>
> </outbound-socket-binding>
> <outbound-socket-binding name="node2">
> <remote-destination host="IP-B" port="8080"/>
> </outbound-socket-binding>
> </socket-binding-group>
> </socket-binding-groups>
> where IP-A is the Ip of the host with domain controller and a server, and IP-B is the address of the host with only a server instance.
> If I invert those two IPs HornetQ doesn't create the bridge! The topic isn't shared, every message is processed only by the topic owned by the current server.
> Why the order of sucjh addresses determines the correct behaviour of the messaging subsystem? I haven't found anything useful on the documentation, am I missing something??
> This is the line which is written only in the order proposed which starts the HornetQ shared topics:
> 2016-06-20 12:18:17,943 INFO [org.hornetq.core.server] (Thread-29 (HornetQ-server-HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead-2097612799)) HQ221027: Bridge ClusterConnectionBridge@4862c348 [name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, queue=QueueImpl[name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead]]@4ceda5a4 targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@4862c348 [name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, queue=QueueImpl[name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead]]@4ceda5a4 targetConnector=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&http-upgrade-endpoint=http-acceptor&host=IP_B&http-upgrade-enabled=true], discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1383156397[nodeUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead, connector=TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=IP-A&http-upgrade-endpoint=http-acceptor&http-upgrade-enabled=true, address=jms, server=HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead])) [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&http-upgrade-endpoint=http-acceptor&host=IP-B&http-upgrade-enabled=true], discoveryGroupConfiguration=null]] is connected
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months