[
https://issues.apache.org/jira/browse/ARTEMIS-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16352525#comment-16352525
]
ASF GitHub Bot commented on ARTEMIS-1656:
-----------------------------------------
Github user franz1981 commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1849#discussion_r166001786
--- Diff:
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireConnection.java
---
@@ -248,8 +255,13 @@ private ConnectionInfo getConnectionInfo() {
//tells the connection that
//some bytes just sent
- public void bufferSent() {
- lastSent = System.currentTimeMillis();
+ private void bufferSent() {
+ //much cheaper than a volatile set if contended, but less precise
(ie allows stale loads)
+ LAST_SENT_UPDATER.lazySet(this, System.currentTimeMillis());
+ }
+
+ private static void traceBufferReceived(Object connectionID, Command
command) {
--- End diff --
can't say if it has the same reason and could be addressed in that way: I
do not need specific/common handling of those trace messages, but instead a way
to packed them in separate methods leaving the callers smaller and able to be
eligible for inlining.
Making them more generic just for perf reasons could be even worst wdyt?
> OpenWire scalability improvements
> ---------------------------------
>
> Key: ARTEMIS-1656
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1656
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Minor
>
> OpenWire is using the synchronized OpenWireFormat instance belonging to
> OpenWireProtocolManager: it won't allow to scale with the number of
> connections.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
