[jira] [Commented] (ARTEMIS-2828) Add addressSize as metric
[
https://issues.apache.org/jira/browse/ARTEMIS-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153160#comment-17153160
]
ASF subversion and git services commented on ARTEMIS-2828:
--
Commit 61d2f58aab712ed6fd4bc748277a7e7ae3073962 in activemq-artemis's branch
refs/heads/master from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=61d2f58 ]
ARTEMIS-2828 Fixing ManagementServiceImplTest
> Add addressSize as metric
> -
>
> Key: ARTEMIS-2828
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2828
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> The {{addressSize}} is already available via the management API (via the
> {{AddressControl}}). This should also be exported to the metrics subsystem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2696) Netty DirectBufferLeak noticed in the log and server not processing messages with out of direct memory errors after running for a day
[
https://issues.apache.org/jira/browse/ARTEMIS-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153115#comment-17153115
]
Luis Miguel De Bello edited comment on ARTEMIS-2696 at 7/7/20, 10:21 PM:
-
-I have just realized the commit
[https://github.com/apache/activemq-artemis/commit/9fac4b866cf9cefbb6f7c13b820e07455b6649f5]
replace the "wsencoder" using the new implementation, however the original one
is coming from netty and implements ByteBufHolder so I think this issue was not
happening because some point later the method "release" was called releasing
the buffer, I think we could do the same logic for WebSocketServerHandler. I
will check this, please let me know your opinion.-
Review 1
I have just check and "ContinuationWebSocketFrame" is a ByteBufHolder, so it
should work in the same way :(.
Review 2
Me again :), it is still true because the original byteBuf is not release.
that is the reason why adding in ProtonHandler works, nobody release the
byteBuf. not sure who is the owner, it seems it belong to the
ContinuationWebSocketFrame to do this in the last frame, based on the logic of
other frame
Review 3
It seems better to release this in the WebSocketFrameEncoder because the buffer
was already copied. I will go on this path to try to fix it.
sorry for the back and forth with myself.
was (Author: ldebello):
-I have just realized the commit
[https://github.com/apache/activemq-artemis/commit/9fac4b866cf9cefbb6f7c13b820e07455b6649f5]
replace the "wsencoder" using the new implementation, however the original one
is coming from netty and implements ByteBufHolder so I think this issue was not
happening because some point later the method "release" was called releasing
the buffer, I think we could do the same logic for WebSocketServerHandler. I
will check this, please let me know your opinion.-
I have just check and "ContinuationWebSocketFrame" is a ByteBufHolder, so it
should work in the same way :(.
Me again :), it is still true because the original byteBuf is not release. that
is the reason why adding in ProtonHandler works, nobody release the byteBuf.
not sure who is the owner, it seems it belong to the ContinuationWebSocketFrame
to do this in the last frame, based on the logic of other frame
> Netty DirectBufferLeak noticed in the log and server not processing messages
> with out of direct memory errors after running for a day
> -
>
> Key: ARTEMIS-2696
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2696
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.11.0, 2.13.0
> Environment: Ubuntu 18.04.1 LTS
> Netty 4.1.45
> Qpid 0.48
>
>
>Reporter: Bas
>Priority: Major
> Attachments: HttpKeepAliveRunnable.png
>
>
> Our servers started to crash daily once we were on the 2.11.0 version.
> The crashes were not killing the entire artemis server but will cause endless
> log statements of the following:
> {noformat}
> Transport failed: io.netty.util.internal.OutOfDirectMemoryError: failed to
> allocate 16777216 byte(s) of direct memory (used: 637534215, max: 652738560)
> {noformat}
> We launched an investigation and activated the netty advanced leak detection:
> {{-Dio.netty.leakDetectionLevel=advanced}}
> After which we indeed noticed leak detection log entries with following
> information:
> #1:
> {noformat}
> io.netty.buffer.AdvancedLeakAwareByteBuf.readBytes(AdvancedLeakAwareByteBuf.java:484)
>
> org.apache.activemq.artemis.core.server.protocol.websocket.WebSocketFrameEncoder.writeContinuationFrame(WebSocketFrameEncoder.java:56)
>
> org.apache.activemq.artemis.core.server.protocol.websocket.WebSocketFrameEncoder.write(WebSocketFrameEncoder.java:45)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:715)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:762)
>
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:788)
>
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:756)
>
> io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1020)
>
> io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:299)
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:382)
>
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:286)
>
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:281)
>
>
[jira] [Comment Edited] (ARTEMIS-2696) Netty DirectBufferLeak noticed in the log and server not processing messages with out of direct memory errors after running for a day
[
https://issues.apache.org/jira/browse/ARTEMIS-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153115#comment-17153115
]
Luis Miguel De Bello edited comment on ARTEMIS-2696 at 7/7/20, 10:17 PM:
-
-I have just realized the commit
[https://github.com/apache/activemq-artemis/commit/9fac4b866cf9cefbb6f7c13b820e07455b6649f5]
replace the "wsencoder" using the new implementation, however the original one
is coming from netty and implements ByteBufHolder so I think this issue was not
happening because some point later the method "release" was called releasing
the buffer, I think we could do the same logic for WebSocketServerHandler. I
will check this, please let me know your opinion.-
I have just check and "ContinuationWebSocketFrame" is a ByteBufHolder, so it
should work in the same way :(.
Me again :), it is still true because the original byteBuf is not release. that
is the reason why adding in ProtonHandler works, nobody release the byteBuf.
not sure who is the owner, it seems it belong to the ContinuationWebSocketFrame
to do this in the last frame, based on the logic of other frame
was (Author: ldebello):
-I have just realized the commit
[https://github.com/apache/activemq-artemis/commit/9fac4b866cf9cefbb6f7c13b820e07455b6649f5]
replace the "wsencoder" using the new implementation, however the original one
is coming from netty and implements ByteBufHolder so I think this issue was not
happening because some point later the method "release" was called releasing
the buffer, I think we could do the same logic for WebSocketServerHandler. I
will check this, please let me know your opinion.-
I have just check and "ContinuationWebSocketFrame" is a ByteBufHolder, so it
should work in the same way :(
> Netty DirectBufferLeak noticed in the log and server not processing messages
> with out of direct memory errors after running for a day
> -
>
> Key: ARTEMIS-2696
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2696
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.11.0, 2.13.0
> Environment: Ubuntu 18.04.1 LTS
> Netty 4.1.45
> Qpid 0.48
>
>
>Reporter: Bas
>Priority: Major
> Attachments: HttpKeepAliveRunnable.png
>
>
> Our servers started to crash daily once we were on the 2.11.0 version.
> The crashes were not killing the entire artemis server but will cause endless
> log statements of the following:
> {noformat}
> Transport failed: io.netty.util.internal.OutOfDirectMemoryError: failed to
> allocate 16777216 byte(s) of direct memory (used: 637534215, max: 652738560)
> {noformat}
> We launched an investigation and activated the netty advanced leak detection:
> {{-Dio.netty.leakDetectionLevel=advanced}}
> After which we indeed noticed leak detection log entries with following
> information:
> #1:
> {noformat}
> io.netty.buffer.AdvancedLeakAwareByteBuf.readBytes(AdvancedLeakAwareByteBuf.java:484)
>
> org.apache.activemq.artemis.core.server.protocol.websocket.WebSocketFrameEncoder.writeContinuationFrame(WebSocketFrameEncoder.java:56)
>
> org.apache.activemq.artemis.core.server.protocol.websocket.WebSocketFrameEncoder.write(WebSocketFrameEncoder.java:45)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:715)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:762)
>
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:788)
>
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:756)
>
> io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1020)
>
> io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:299)
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:382)
>
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:286)
>
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:281)
>
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPConnectionCallback.onTransport(AMQPConnectionCallback.java:203)
>
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.pushBytes(AMQPConnectionContext.java:384)
>
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.actualFlush(ProtonHandler.java:210)
>
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
>
>
[jira] [Comment Edited] (ARTEMIS-2696) Netty DirectBufferLeak noticed in the log and server not processing messages with out of direct memory errors after running for a day
[
https://issues.apache.org/jira/browse/ARTEMIS-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153115#comment-17153115
]
Luis Miguel De Bello edited comment on ARTEMIS-2696 at 7/7/20, 10:13 PM:
-
-I have just realized the commit
[https://github.com/apache/activemq-artemis/commit/9fac4b866cf9cefbb6f7c13b820e07455b6649f5]
replace the "wsencoder" using the new implementation, however the original one
is coming from netty and implements ByteBufHolder so I think this issue was not
happening because some point later the method "release" was called releasing
the buffer, I think we could do the same logic for WebSocketServerHandler. I
will check this, please let me know your opinion.-
I have just check and "ContinuationWebSocketFrame" is a ByteBufHolder, so it
should work in the same way :(
was (Author: ldebello):
I have just realized the commit
[https://github.com/apache/activemq-artemis/commit/9fac4b866cf9cefbb6f7c13b820e07455b6649f5]
replace the "wsencoder" using the new implementation, however the original one
is coming from netty and implements ByteBufHolder so I think this issue was not
happening because some point later the method "release" was called releasing
the buffer, I think we could do the same logic for WebSocketServerHandler. I
will check this, please let me know your opinion
> Netty DirectBufferLeak noticed in the log and server not processing messages
> with out of direct memory errors after running for a day
> -
>
> Key: ARTEMIS-2696
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2696
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.11.0, 2.13.0
> Environment: Ubuntu 18.04.1 LTS
> Netty 4.1.45
> Qpid 0.48
>
>
>Reporter: Bas
>Priority: Major
> Attachments: HttpKeepAliveRunnable.png
>
>
> Our servers started to crash daily once we were on the 2.11.0 version.
> The crashes were not killing the entire artemis server but will cause endless
> log statements of the following:
> {noformat}
> Transport failed: io.netty.util.internal.OutOfDirectMemoryError: failed to
> allocate 16777216 byte(s) of direct memory (used: 637534215, max: 652738560)
> {noformat}
> We launched an investigation and activated the netty advanced leak detection:
> {{-Dio.netty.leakDetectionLevel=advanced}}
> After which we indeed noticed leak detection log entries with following
> information:
> #1:
> {noformat}
> io.netty.buffer.AdvancedLeakAwareByteBuf.readBytes(AdvancedLeakAwareByteBuf.java:484)
>
> org.apache.activemq.artemis.core.server.protocol.websocket.WebSocketFrameEncoder.writeContinuationFrame(WebSocketFrameEncoder.java:56)
>
> org.apache.activemq.artemis.core.server.protocol.websocket.WebSocketFrameEncoder.write(WebSocketFrameEncoder.java:45)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:715)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:762)
>
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:788)
>
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:756)
>
> io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1020)
>
> io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:299)
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:382)
>
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:286)
>
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:281)
>
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPConnectionCallback.onTransport(AMQPConnectionCallback.java:203)
>
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.pushBytes(AMQPConnectionContext.java:384)
>
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.actualFlush(ProtonHandler.java:210)
>
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
>
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
>
> io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> {noformat}
>
> #2: Hint: 'websocket-frame-encoder' will handle the
[jira] [Commented] (ARTEMIS-2828) Add addressSize as metric
[
https://issues.apache.org/jira/browse/ARTEMIS-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152892#comment-17152892
]
ASF subversion and git services commented on ARTEMIS-2828:
--
Commit 832bd85941cdba0e8fb33a1ba42bc98dc64610c7 in activemq-artemis's branch
refs/heads/master from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=832bd85 ]
ARTEMIS-2828 Fixing tests after main change on ManagementServiceImpl
This is almost a NO-JIRA, but since I'm fixing
ManagementServiceImplTest.testGetResources broken after this
I'm commiting this change associated with ARTEMIS-2828
> Add addressSize as metric
> -
>
> Key: ARTEMIS-2828
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2828
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> The {{addressSize}} is already available via the management API (via the
> {{AddressControl}}). This should also be exported to the metrics subsystem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2828) Add addressSize as metric
[
https://issues.apache.org/jira/browse/ARTEMIS-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152893#comment-17152893
]
ASF subversion and git services commented on ARTEMIS-2828:
--
Commit 832bd85941cdba0e8fb33a1ba42bc98dc64610c7 in activemq-artemis's branch
refs/heads/master from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=832bd85 ]
ARTEMIS-2828 Fixing tests after main change on ManagementServiceImpl
This is almost a NO-JIRA, but since I'm fixing
ManagementServiceImplTest.testGetResources broken after this
I'm commiting this change associated with ARTEMIS-2828
> Add addressSize as metric
> -
>
> Key: ARTEMIS-2828
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2828
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> The {{addressSize}} is already available via the management API (via the
> {{AddressControl}}). This should also be exported to the metrics subsystem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-7457) Support wider password encryption schemes
[ https://issues.apache.org/jira/browse/AMQ-7457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152767#comment-17152767 ] Kevin Goerlitz commented on AMQ-7457: - Would it be possible to get this merged into the next 5.15.x maintenance release? > Support wider password encryption schemes > - > > Key: AMQ-7457 > URL: https://issues.apache.org/jira/browse/AMQ-7457 > Project: ActiveMQ > Issue Type: Improvement > Components: Security/JAAS >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 5.16.0 > > Time Spent: 20m > Remaining Estimate: 0h > > For password encryption we only support the (default) algorithm > PBEWithMD5AndDES. This task is to support more modern PBE algorithms for: > * The activemq encrypt/decrypt script > * JAAS properties > In addition, we could use the more modern jasypt-spring4 dependency instead > of jasypt-spring13 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2817) Support Stomp subscription with FQQN+multicast
[ https://issues.apache.org/jira/browse/ARTEMIS-2817?focusedWorklogId=455407=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-455407 ] ASF GitHub Bot logged work on ARTEMIS-2817: --- Author: ASF GitHub Bot Created on: 07/Jul/20 12:21 Start Date: 07/Jul/20 12:21 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3202: URL: https://github.com/apache/activemq-artemis/pull/3202 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 455407) Time Spent: 20m (was: 10m) > Support Stomp subscription with FQQN+multicast > -- > > Key: ARTEMIS-2817 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2817 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: STOMP >Affects Versions: 2.13.0 >Reporter: BENJAMIN Lee WARRICK >Assignee: Justin Bertram >Priority: Major > Attachments: artemis.log, broker.xml > > Time Spent: 20m > Remaining Estimate: 0h > > I've been using stompy.py (version 5.0.1) to publish and subscribe on Artemis > 2.8.1. However now that installed a new instance, this time Artemis 2.13.0., > the client fails to subscribe. I can successfully publish to the address with > STOMP, but when I try to subscribe to a queue, I get the following error: > "received an error "AMQ229019: Queue [queue name] already exists on address > [address name]" > And no messages are pulled. I also tried upgrading to stomp.py 6.0, but I > still get the same error. Using a Java JMS client I am able to subscribe. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2817) Support Stomp subscription with FQQN+multicast
[ https://issues.apache.org/jira/browse/ARTEMIS-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152711#comment-17152711 ] ASF subversion and git services commented on ARTEMIS-2817: -- Commit 20daf2354cb740a03104025317237bdda1bc57bd in activemq-artemis's branch refs/heads/master from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=20daf23 ] ARTEMIS-2817 Support Stomp subscription with FQQN+multicast > Support Stomp subscription with FQQN+multicast > -- > > Key: ARTEMIS-2817 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2817 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: STOMP >Affects Versions: 2.13.0 >Reporter: BENJAMIN Lee WARRICK >Assignee: Justin Bertram >Priority: Major > Attachments: artemis.log, broker.xml > > Time Spent: 10m > Remaining Estimate: 0h > > I've been using stompy.py (version 5.0.1) to publish and subscribe on Artemis > 2.8.1. However now that installed a new instance, this time Artemis 2.13.0., > the client fails to subscribe. I can successfully publish to the address with > STOMP, but when I try to subscribe to a queue, I get the following error: > "received an error "AMQ229019: Queue [queue name] already exists on address > [address name]" > And no messages are pulled. I also tried upgrading to stomp.py 6.0, but I > still get the same error. Using a Java JMS client I am able to subscribe. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2834) Leaking meters
[ https://issues.apache.org/jira/browse/ARTEMIS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152709#comment-17152709 ] ASF subversion and git services commented on ARTEMIS-2834: -- Commit f5d57101d92f657f620858f827a7402b25eb in activemq-artemis's branch refs/heads/master from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f5d5710 ] ARTEMIS-2834 leaking meters Move all of the meter registration code into the ManagementServer implementation to provide better life-cycle management. > Leaking meters > -- > > Key: ARTEMIS-2834 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2834 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > After failback the backup's meters aren't cleaned up properly so they report > stale data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2825) Wrong calculation for DiskStoreUsagePercentage
[
https://issues.apache.org/jira/browse/ARTEMIS-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152705#comment-17152705
]
ASF subversion and git services commented on ARTEMIS-2825:
--
Commit 26091f1907dce5a1a9dd9f0d6a5ca976166a5c41 in activemq-artemis's branch
refs/heads/master from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=26091f1 ]
ARTEMIS-2825 wrong calc for DiskStoreUsagePercentage
The calculation used by
ActiveMQServerControlImpl.getDiskStoreUsagePercentage() is incorrect. It
uses disk space info with global-max-size which is for address memory.
Also, the existing getDiskStoreUsage() method *already* returns a
percentage of total disk store usage so this method seems redundant.
> Wrong calculation for DiskStoreUsagePercentage
> ---
>
> Key: ARTEMIS-2825
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2825
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> The calculation used by
> {{org.apache.activemq.artemis.core.management.impl.ActiveMQServerControlImpl.getDiskStoreUsagePercentage()}}
> is incorrect. It uses disk space info with global-max-size which is for
> address memory. Also, the existing {{getDiskStoreUsage()}} method _already_
> returns a percentage of total disk store usage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2827) Add addressMemoryUsagePercentage as metric
[
https://issues.apache.org/jira/browse/ARTEMIS-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152706#comment-17152706
]
ASF subversion and git services commented on ARTEMIS-2827:
--
Commit ac8ffedf668f2733dbfb4eb1305a50bbd263e5d3 in activemq-artemis's branch
refs/heads/master from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=ac8ffed ]
ARTEMIS-2827 add addressMemoryUsagePercentage as metric
> Add addressMemoryUsagePercentage as metric
> --
>
> Key: ARTEMIS-2827
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2827
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> The {{addressMemoryUsagePercentage}} is already available via the management
> API (via the {{ActiveMQServerControl}}). This should also be exported to the
> metrics subsystem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2828) Add addressSize as metric
[
https://issues.apache.org/jira/browse/ARTEMIS-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152707#comment-17152707
]
ASF subversion and git services commented on ARTEMIS-2828:
--
Commit cb7cd729d7ef4a0bebca8d443300ac38d7a9f873 in activemq-artemis's branch
refs/heads/master from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=cb7cd72 ]
ARTEMIS-2828 add addressSize metric
Adding this metric required moving the meter registration code from the
AddressInfo class to the ManagementService in order to get clean access
to both the AddressInfo and AddressControl classes.
> Add addressSize as metric
> -
>
> Key: ARTEMIS-2828
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2828
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> The {{addressSize}} is already available via the management API (via the
> {{AddressControl}}). This should also be exported to the metrics subsystem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2829) Wrong return type for getDiskStoreUsage
[ https://issues.apache.org/jira/browse/ARTEMIS-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152708#comment-17152708 ] ASF subversion and git services commented on ARTEMIS-2829: -- Commit fd207e75b0bb94005d953bfc780e7b8ee7c166c8 in activemq-artemis's branch refs/heads/master from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fd207e7 ] ARTEMIS-2829 wrong return type for getDiskStoreUsage Since getDiskStoreUsage on the ActiveMQServerControl is converting a double to a long the value is always 0 in the management API. It should return a double instead. > Wrong return type for getDiskStoreUsage > --- > > Key: ARTEMIS-2829 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2829 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2797) Reset queue properties by unsetting them in broker.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-2797?focusedWorklogId=455402=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-455402 ] ASF GitHub Bot logged work on ARTEMIS-2797: --- Author: ASF GitHub Bot Created on: 07/Jul/20 12:07 Start Date: 07/Jul/20 12:07 Worklog Time Spent: 10m Work Description: clebertsuconic edited a comment on pull request #3213: URL: https://github.com/apache/activemq-artemis/pull/3213#issuecomment-654549647 @jsmucr: never mind, when I read this: "Regular calls to PostOfficeImpl#updateQueue are no longer affected." I thought it meant that updateQueue would no longer have any effect... I read it again.. and I see the real meaning. I am adding a new commit to fix the offended tests.. if you could please review it? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 455402) Time Spent: 8h 10m (was: 8h) > Reset queue properties by unsetting them in broker.xml > -- > > Key: ARTEMIS-2797 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2797 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.13.0 >Reporter: Jan Šmucr >Priority: Major > Labels: pull-request-available > Fix For: 2.14.0 > > Time Spent: 8h 10m > Remaining Estimate: 0h > > Currently the queue properties cannot be removed because of property new > value null checks leading to quitting the PostOfficeImpl#updateQueue() > instead of resetting the properties to their default values. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2797) Reset queue properties by unsetting them in broker.xml
[
https://issues.apache.org/jira/browse/ARTEMIS-2797?focusedWorklogId=455401=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-455401
]
ASF GitHub Bot logged work on ARTEMIS-2797:
---
Author: ASF GitHub Bot
Created on: 07/Jul/20 12:06
Start Date: 07/Jul/20 12:06
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3213:
URL: https://github.com/apache/activemq-artemis/pull/3213#discussion_r450814008
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java
##
@@ -701,7 +701,7 @@ public QueueBinding updateQueue(QueueConfiguration
queueConfiguration, boolean f
final SimpleString empty = new SimpleString("");
Filter oldFilter = FilterImpl.createFilter(queue.getFilter() ==
null ? empty : queue.getFilter().getFilterString());
Filter newFilter =
FilterImpl.createFilter(queueConfiguration.getFilterString() == null ? empty :
queueConfiguration.getFilterString());
-if ((forceUpdate || newFilter != null) &&
!Objects.equals(oldFilter, newFilter)) {
+if ((forceUpdate || newFilter != oldFilter) &&
!Objects.equals(oldFilter, newFilter)) {
Review comment:
@jsmucr merged, thank you
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 455401)
Time Spent: 8h (was: 7h 50m)
> Reset queue properties by unsetting them in broker.xml
> --
>
> Key: ARTEMIS-2797
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2797
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.13.0
>Reporter: Jan Šmucr
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.14.0
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> Currently the queue properties cannot be removed because of property new
> value null checks leading to quitting the PostOfficeImpl#updateQueue()
> instead of resetting the properties to their default values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2797) Reset queue properties by unsetting them in broker.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-2797?focusedWorklogId=455400=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-455400 ] ASF GitHub Bot logged work on ARTEMIS-2797: --- Author: ASF GitHub Bot Created on: 07/Jul/20 12:05 Start Date: 07/Jul/20 12:05 Worklog Time Spent: 10m Work Description: asfgit merged pull request #3213: URL: https://github.com/apache/activemq-artemis/pull/3213 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 455400) Time Spent: 7h 50m (was: 7h 40m) > Reset queue properties by unsetting them in broker.xml > -- > > Key: ARTEMIS-2797 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2797 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.13.0 >Reporter: Jan Šmucr >Priority: Major > Labels: pull-request-available > Fix For: 2.14.0 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > Currently the queue properties cannot be removed because of property new > value null checks leading to quitting the PostOfficeImpl#updateQueue() > instead of resetting the properties to their default values. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2797) Reset queue properties by unsetting them in broker.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152698#comment-17152698 ] ASF subversion and git services commented on ARTEMIS-2797: -- Commit 3f99c4b84613d88a9caba4cb4cf15f6cb0bb1a13 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3f99c4b ] ARTEMIS-2797 Fixing updateQueue on filter / fixing ActiveMQServerControlTest > Reset queue properties by unsetting them in broker.xml > -- > > Key: ARTEMIS-2797 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2797 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.13.0 >Reporter: Jan Šmucr >Priority: Major > Labels: pull-request-available > Fix For: 2.14.0 > > Time Spent: 7h 40m > Remaining Estimate: 0h > > Currently the queue properties cannot be removed because of property new > value null checks leading to quitting the PostOfficeImpl#updateQueue() > instead of resetting the properties to their default values. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2797) Reset queue properties by unsetting them in broker.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152697#comment-17152697 ] ASF subversion and git services commented on ARTEMIS-2797: -- Commit 6cc370e169e16c29f9c2df5622654b264b730fe9 in activemq-artemis's branch refs/heads/master from Jan Šmucr [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=6cc370e ] ARTEMIS-2797 Fixing redeploy mechanism Queue settings are reset to their default values upon broker.xml reload ONLY. Regular calls to PostOfficeImpl#updateQueue are no longer affected. > Reset queue properties by unsetting them in broker.xml > -- > > Key: ARTEMIS-2797 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2797 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.13.0 >Reporter: Jan Šmucr >Priority: Major > Labels: pull-request-available > Fix For: 2.14.0 > > Time Spent: 7h 40m > Remaining Estimate: 0h > > Currently the queue properties cannot be removed because of property new > value null checks leading to quitting the PostOfficeImpl#updateQueue() > instead of resetting the properties to their default values. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2835) Porting HORNETQ-1575 and HORNETQ-1578
[ https://issues.apache.org/jira/browse/ARTEMIS-2835?focusedWorklogId=455345=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-455345 ] ASF GitHub Bot logged work on ARTEMIS-2835: --- Author: ASF GitHub Bot Created on: 07/Jul/20 10:55 Start Date: 07/Jul/20 10:55 Worklog Time Spent: 10m Work Description: gaohoward commented on pull request #3211: URL: https://github.com/apache/activemq-artemis/pull/3211#issuecomment-654772110 @clebertsuconic I've updated the branch and checked all fedoration tests passed. Also investigated other tests and seems the RedeployTest has some real failures but not related to this PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 455345) Time Spent: 1h (was: 50m) > Porting HORNETQ-1575 and HORNETQ-1578 > - > > Key: ARTEMIS-2835 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2835 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.13.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.14.0 > > Time Spent: 1h > Remaining Estimate: 0h > > The HORNETQ-1575 and HORNETQ-1578 bug fixes are not available in Artemis. It > could be hit by users in Artemis too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQ-7510) Message caching behavior not consistent
Vasa created AMQ-7510: - Summary: Message caching behavior not consistent Key: AMQ-7510 URL: https://issues.apache.org/jira/browse/AMQ-7510 Project: ActiveMQ Issue Type: Bug Reporter: Vasa tl;dr: Broker memory usage not consistent after reboots Steps to reproduce the issue: * Created a broker (Both on a personal instance as well as with AmazonMQ) * Started producing messages directly to one or more destination queues without any consumers polling the queue * All messages were sent to the broker with persistent mode * As messages are sent to the queue, the memory % rise as seen from the ActiveMQ console. It can go all the way up to 99% after which it starts rejecting messages * Once the broker is rebooted, the memory percent goes down to 0 even when the queue still has all the messages. * When continuing to send additional messages, the memory percent does not go up It almost seems like caching led to memory % rise until broker reboot. After reboot, caching of messages was not active and memory % stayed down -- This message was sent by Atlassian Jira (v8.3.4#803005)
