[jira] [Commented] (AMQ-8093) Illegal reflective access by IntrospectionSupport
[ https://issues.apache.org/jira/browse/AMQ-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247934#comment-17247934 ] Scott M Messner commented on AMQ-8093: -- Is this a planned correction in the Client component ? (Still specified as Broker) Just FYI: - [https://stackoverflow.com/questions/50251798/what-is-an-illegal-reflective-access] - [https://openjdk.java.net/jeps/261#Relaxed-strong-encapsulation] > Illegal reflective access by IntrospectionSupport > - > > Key: AMQ-8093 > URL: https://issues.apache.org/jira/browse/AMQ-8093 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.13 > Environment: Java 11 >Reporter: John C >Assignee: Jean-Baptiste Onofré >Priority: Major > > This warning occurred when we try to connect to ActiveMQ using SSL in a > springboot application: > > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.activemq.util.IntrospectionSupport > (file:/C:/Users/user/.m2/repository/org/apache/activemq/activemq-client/5.15.13/activemq-client-5.15.13.jar) > to method sun.security.ssl.SSLSocketImpl.setHost(java.lang.String) > WARNING: Please consider reporting this to the maintainers of > org.apache.activemq.util.IntrospectionSupport > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > > > > WARNING: Illegal reflective access by > org.apache.activemq.util.IntrospectionSupport > (file:/C:/Users/user/.m2/repository/org/apache/activemq/activemq-client/5.15.13/activemq-client-5.15.13.jar) > to method sun.security.ssl.SSLSocketImpl.setHost(java.lang.String) at > org.apache.activemq.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:181) > at > org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:155) > at > org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:140) > at > org.apache.activemq.transport.tcp.SslTransport.(SslTransport.java:81) > at > org.apache.activemq.transport.tcp.SslTransportFactory.createTransport(SslTransportFactory.java:122) > at > org.apache.activemq.transport.TransportFactory.doConnect(TransportFactory.java:120) > at > org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:65) > at > org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:331) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-8091) ClientIdSet indefinitely contains obsolete ids (when connection is not closed properly)
[ https://issues.apache.org/jira/browse/AMQ-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241684#comment-17241684 ] Scott M Messner commented on AMQ-8091: -- Thanks for picking this up. Yes, this is most certainly due to abnormally/abruptly closing connections where clientId is being set. I'll try generating a test by the end of tomorrow. > ClientIdSet indefinitely contains obsolete ids (when connection is not closed > properly) > --- > > Key: AMQ-8091 > URL: https://issues.apache.org/jira/browse/AMQ-8091 > Project: ActiveMQ > Issue Type: Bug > Components: Transport >Affects Versions: 5.16.0 > Environment: ActiveMQ 5.16.0 standalone running on ec2-equivalent VMs > with CentOS7. >Reporter: Scott M Messner >Assignee: Matt Pavlovich >Priority: Minor > Labels: clientId > Attachments: AMQBrorkerTraces_obsoletClientId.txt, > AMQClientTraces_obsoletClientId.txt > > > Hello Everyone, > I'm trying to debug some strange issues with my cloud-deployed ActiveMQ > Broker. I've run into an unfortunate side-bug. I figured I would present this > particular problem with hopes that someone else might have the time to write > the test and reproduce. If not, I'll come back later with the test to > reproduce on a more functional deployment. > My current brokers are manifesting some strange transport issues where my > client is able to successfully connect, but thereafter does nothing (no > authentication, no opening of sessions, etc). This, I imagine is a deeper > networking issue that I intend to investigate further. If I find more info I > may create a separate issue. > At the same time, I noticed that re-running my test fails with > javax.jms.InvalidClientIDException – The clientId is already taken. It > remains this way indefinitely. The activemq admin console does not show any > connections with this particular clientId. > When reviewing the code I can see that clientIds are removed from the > clientIdSet during the Broker.removeConnection() method. > If the connection is not closed properly will there be a sort of connection > garbage collection (the same that is done for unused destinations for > example) that will ensure the these clientIds are removed from the set ? > Thanks in advance for your help. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQ-8091) ClientIdSet indefinitely contains obsolete ids (when connection is not closed properly)
Scott M Messner created AMQ-8091: Summary: ClientIdSet indefinitely contains obsolete ids (when connection is not closed properly) Key: AMQ-8091 URL: https://issues.apache.org/jira/browse/AMQ-8091 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 5.16.0 Environment: ActiveMQ 5.16.0 standalone running on ec2-equivalent VMs with CentOS7. Reporter: Scott M Messner Attachments: AMQBrorkerTraces_obsoletClientId.txt, AMQClientTraces_obsoletClientId.txt Hello Everyone, I'm trying to debug some strange issues with my cloud-deployed ActiveMQ Broker. I've run into an unfortunate side-bug. I figured I would present this particular problem with hopes that someone else might have the time to write the test and reproduce. If not, I'll come back later with the test to reproduce on a more functional deployment. My current brokers are manifesting some strange transport issues where my client is able to successfully connect, but thereafter does nothing (no authentication, no opening of sessions, etc). This, I imagine is a deeper networking issue that I intend to investigate further. If I find more info I may create a separate issue. At the same time, I noticed that re-running my test fails with javax.jms.InvalidClientIDException – The clientId is already taken. It remains this way indefinitely. The activemq admin console does not show any connections with this particular clientId. When reviewing the code I can see that clientIds are removed from the clientIdSet during the Broker.removeConnection() method. If the connection is not closed properly will there be a sort of connection garbage collection (the same that is done for unused destinations for example) that will ensure the these clientIds are removed from the set ? Thanks in advance for your help. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQ-8089) ProviderVersion being reported as 5.15.10 in version 5.16.0
Scott M Messner created AMQ-8089:
Summary: ProviderVersion being reported as 5.15.10 in version
5.16.0
Key: AMQ-8089
URL: https://issues.apache.org/jira/browse/AMQ-8089
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 5.16.0
Reporter: Scott M Messner
Hello,
I'm debugging a separate problem, but I stumbled upon this. The client rxd an
unexpected ProviderVersion. Just wanted to make sure, is this normal ?
17:06:50.999 [ActiveMQ Transport: ssl://blackstrype.com/xxx.xxx.xxx.xxx:y]
DEBUG o.a.a.transport.InactivityMonitor - Using min of local: WireFormatInfo {
version=12, properties={TcpNoDelayEnabled=true, SizePrefixDisabled=false,
CacheSize=1024, ProviderName=ActiveMQ, StackTraceEnabled=true,
PlatformDetails=Java, CacheEnabled=true, TightEncodingEnabled=true,
MaxFrameSize=9223372036854775807, MaxInactivityDuration=3,
MaxInactivityDurationInitalDelay=1,
+{color:#de350b}*ProviderVersion=5.15.10*{color}+}, magic=[A,c,t,i,v,e,M,Q]}
and remote: WireFormatInfo { version=12, properties={TcpNoDelayEnabled=true,
SizePrefixDisabled=false, CacheSize=1024, ProviderName=ActiveMQ,
StackTraceEnabled=true, PlatformDetails=Java, CacheEnabled=true,
TightEncodingEnabled=true, MaxFrameSize=9223372036854775807,
MaxInactivityDuration=3, MaxInactivityDurationInitalDelay=1,
{color:#00875a}ProviderVersion=5.16.0{color}}, magic=[A,c,t,i,v,e,M,Q]}
17:06:50.999 [ActiveMQ Transport: ssl://blackstrype.com/xxx.xxx.xxx.xxx:y]
DEBUG o.a.a.transport.WireFormatNegotiator - Received WireFormat:
WireFormatInfo \{ version=12, properties={TcpNoDelayEnabled=true,
SizePrefixDisabled=false, CacheSize=1024, ProviderName=ActiveMQ,
StackTraceEnabled=true, PlatformDetails=Java, CacheEnabled=true,
TightEncodingEnabled=true, MaxFrameSize=9223372036854775807,
MaxInactivityDuration=3, MaxInactivityDurationInitalDelay=1,
ProviderVersion=5.16.0}, magic=[A,c,t,i,v,e,M,Q]}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17223562#comment-17223562 ] Scott M Messner commented on AMQ-7514: -- Regardless of the the racial charge of the 'master' and 'slave' terminology – it's actually quite incorrect for what it implies and the actual usage. For example: I use [https://activemq.apache.org/jdbc-master-slave] . I think the fitting term is 'active' and 'passive'. I can maybe help in refactoring the doc, but I admit, I've very little experience in open source contributions. Do I just check out the doc, modify, push, and make a pull-request ? Is there a procedure written somewhere for getting started making contributions ? > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQ-7003) expose "FirstMessageAge" in AMQ
Scott M Messner created AMQ-7003: Summary: expose "FirstMessageAge" in AMQ Key: AMQ-7003 URL: https://issues.apache.org/jira/browse/AMQ-7003 Project: ActiveMQ Issue Type: Wish Components: Broker, JMX Affects Versions: 5.15.4 Reporter: Scott M Messner Fix For: 5.x JMSQueueControl.getFirstMessageAge() from the Artemis project is exactly the command we need for our current project. The provided avgEnqueue time is not sufficient for determining realtime peaks of queue/topic usage because the calculation is made solely on consumed messages. Currently, we use queue browsing to calculate this metric, but it is highly inefficient to pull all messages... Is there any plan to implement/expose FirstMessageAge in ActiveMQ 5.x ? Is there, maybe, a workaround to the absence of this metric ? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-5250) temp queue not working after long run of activemq
[ https://issues.apache.org/jira/browse/AMQ-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14646394#comment-14646394 ] Scott M Messner commented on AMQ-5250: -- I believe I found a way to reproduce this error but I don't quite understand what's happening so I'll leave you guys with the code and you can tell me if you need more info: My test consists of ServiceA sending a message and waiting for a response from ServiceB ServiceB sends 5 response messages the 5th of which will be a Shutdown command. I've added a 30 second sleep to induce a FailOverTransport timeout error. The first pass through the test runs fine, throwing the timeout error, but continuing gracefully (bravo ActiveMQ) Running the test a second time will immediately throw the JMSException seen below. 2015-07-29 18:34:35 INFO FailoverTransport:1030 - Successfully connected to tcp://xxx.xxx.xxx.xxx:61616 2015-07-29 18:34:35 INFO FailoverTransport:1030 - Successfully connected to tcp://xxx.xxx.xxx.xxx:61616 2015-07-29 18:34:38 INFO FailoverTransport:1030 - Successfully connected to tcp://xxx.xxx.xxx.xxx:61616 2015-07-29 18:34:38 INFO FailoverTransport:1030 - Successfully connected to tcp://xxx.xxx.xxx.xxx:61616 2015-07-29 18:34:38 ERROR TempDestinationTestServiceB:83 - Error treating message com.blackstrype.mom.MOMException: sendReplyMapMessage JMSException : Cannot publish to a deleted Destination: temp-queue://ID:titoBox-64611-1438187511326-7:1:1 at com.blackstrype.mom.CloudMOM.sendReplyMapMessage(CloudMOM.java:556) at com.blackstrype.mom.test.tempdest.TempDestinationTestServiceB$SandboxListener.onMessage(TempDestinationTestServiceB.java:72) at org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1321) at org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:131) at org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:202) at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129) at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: javax.jms.InvalidDestinationException: Cannot publish to a deleted Destination: temp-queue://ID:titoBox-64611-1438187511326-7:1:1 at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1735) at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:289) at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:224) at org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:300) at com.blackstrype.mom.CloudMOM.sendReplyMapMessage(CloudMOM.java:554) ... 9 more 2015-07-29 18:34:38 INFO TempDestinationTestServiceA:144 - Message response received: id=0, body=Response 0 to: 'abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuv'. 2015-07-29 18:35:08 INFO TempDestinationTestServiceA:144 - Message response received: id=1, body=Response 1 to: 'abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuv'. 2015-07-29 18:35:38 INFO TempDestinationTestServiceA:144 - Message response received: id=2, body=Response 2 to: 'abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuv'. 2015-07-29 18:35:45 WARN FailoverTransport:255 - Transport (tcp://YYY.YYY.YYY.YYY:61616) failed, reason: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>3) long: tcp://YYY.YYY.YYY.YYY:61616, attempting to automatically reconnect 2015-07-29 18:35:45 WARN FailoverTransport:255 - Transport (tcp://YYY.YYY.YYY.YYY:61616) failed, reason: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>3) long: tcp://YYY.YYY.YYY.YYY:61616, attempting to automatically reconnect 2015-07-29 18:35:49 INFO FailoverTransport:1032 - Successfully reconnected to tcp://xxx.xxx.xxx.xxx:61616 2015-07-29 18:35:49 INFO FailoverTransport:1032 - Successfully reconnected to tcp://xxx.xxx.xxx.xxx:61616 2015-07-29 18:36:08 IN
