[jira] [Commented] (ARTEMIS-868) Lost connection to stomp over web socket
[ https://issues.apache.org/jira/browse/ARTEMIS-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15707475#comment-15707475 ] Justin Bertram commented on ARTEMIS-868: The [ActiveMQ User List|http://activemq.apache.org/artemis/community.html] would be a better place to discuss this issue. If it turns out to be a bug then you can raise it here. > Lost connection to stomp over web socket > - > > Key: ARTEMIS-868 > URL: https://issues.apache.org/jira/browse/ARTEMIS-868 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker, Stomp >Affects Versions: 1.4.0, 1.5.0 > Environment: S.O: RHEL 7 >Reporter: ma >Priority: Critical > Fix For: 1.6.0 > > > I'm trying to communicate with artemis beta 1 broker using the stomp over > websocket protocol. But I get the following error message: > Whoops! Lost connection to ws: // localhost: 61614 > To perform the communication I using the stompjs library indicated in the > documentation of the artermis > http://jmesnil.net/stomp-websocket/doc/ > abaixo o log gerado pelo amq artemis: > 15:59:28,348 INFO [org.apache.activemq.artemis.integration.bootstrap] > AMQ101000: Starting ActiveMQ Artemis Server > 15:59:28,369 INFO [org.apache.activemq.artemis.core.server] AMQ221000: live > Message Broker is starting with configuration Broker Configuration > (clustered=false,journalDirectory=./data/journal,bindingsDirectory=./data/bindings,largeMessagesDirectory=./data/large-messages,pagingDirectory=./data/paging) > 15:59:28,406 INFO [org.apache.activemq.artemis.core.server] AMQ221012: Using > AIO Journal > 15:59:28,471 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-server]. Adding protocol support for: CORE > 15:59:28,474 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: > AMQP > 15:59:28,475 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-hornetq-protocol]. Adding protocol support > for: HORNETQ > 15:59:28,476 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: > MQTT > 15:59:28,478 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-openwire-protocol]. Adding protocol support > for: OPENWIRE > 15:59:28,479 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: > STOMP > 15:59:29,078 INFO [org.apache.activemq.artemis.core.server] AMQ221003: > Deploying queue jms.queue.Request > 15:59:29,090 INFO [org.apache.activemq.artemis.core.server] AMQ221003: > Deploying queue jms.queue.DLQ > 15:59:29,093 INFO [org.apache.activemq.artemis.core.server] AMQ221003: > Deploying queue jms.queue.ExpiryQueue > 15:59:30,496 INFO [org.apache.activemq.artemis.core.server] AMQ221020: > Started Acceptor at 0.0.0.0:61614 for protocols [STOMP] > 15:59:30,502 INFO [org.apache.activemq.artemis.core.server] AMQ221020: > Started Acceptor at 0.0.0.0:61616 for protocols > [CORE,MQTT,AMQP,HORNETQ,STOMP,OPENWIRE] > 15:59:30,506 INFO [org.apache.activemq.artemis.core.server] AMQ221020: > Started Acceptor at 0.0.0.0:5445 for protocols [HORNETQ,STOMP] > 15:59:30,510 INFO [org.apache.activemq.artemis.core.server] AMQ221020: > Started Acceptor at 0.0.0.0:5672 for protocols [AMQP] > 15:59:30,514 INFO [org.apache.activemq.artemis.core.server] AMQ221020: > Started Acceptor at 0.0.0.0:1883 for protocols [MQTT] > 15:59:30,517 INFO [org.apache.activemq.artemis.core.server] AMQ221020: > Started Acceptor at 0.0.0.0:61613 for protocols [STOMP] > 15:59:30,518 INFO [org.apache.activemq.artemis.core.server] AMQ221007: > Server is now live > 15:59:30,518 INFO [org.apache.activemq.artemis.core.server] AMQ221001: > Apache ActiveMQ Artemis Message Broker version 1.3.0.amq-75-redhat-1 > [broker, nodeID=4464cd65-a783-11e6-8cb6-fa163e93081c] > SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". > SLF4J: Defaulting to no-operation (NOP) logger implementation > SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further > details. > INFO | main | Initialized artemis-plugin plugin > INFO | main | Initialized dispatch-hawtio-console plugin > 15:59:32,416 INFO [org.apache.activemq.artemis] AMQ241001: HTTP Server > started at http://0.0.0.0:8181 > 15:59:32,417 INFO [org.apache.activemq.artemis] AMQ241002: Artemis Jolokia > REST API available at http://0.0.0.0:8181/jolokia > 16:27:10,645 WARN [org.apache.activemq.artemis.core.server] AMQ222067: > Connection failure has been detected: AMQ119014: Did not receive data from > /10.52.209.9
[jira] [Commented] (AMQ-6262) HTTP transport broken in 5.12
[
https://issues.apache.org/jira/browse/AMQ-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706755#comment-15706755
]
ASF GitHub Bot commented on AMQ-6262:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq/pull/181
> HTTP transport broken in 5.12
> -
>
> Key: AMQ-6262
> URL: https://issues.apache.org/jira/browse/AMQ-6262
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.12.0, 5.12.1, 5.13.0, 5.12.2, 5.13.1, 5.12.3, 5.13.2
>Reporter: Przemek Bruski
>Priority: Critical
> Fix For: 5.13.3, 5.14.0
>
>
> A regression from https://issues.apache.org/jira/browse/AMQ-5794 .
> Connection watchdog is started for every initiated connection and stopped on
> WireFormatInfo command. HTTP transport doesn't send WireFormatInfo so the
> watchdog never realises that the connection has been successfully established.
> The connection gets terminated every 30seconds by the watchdog.
> At the beginning, everything looks fine, but then you start getting
> exceptions and start losing packets. I haven't seen that myself, but I had
> people reporting that if HTTP transports are in use, it eventually
> destabilises the broker and affects non-HTTP transports too.
> {noformat}
> 2016-04-22 10:32:46.029244500 2016-04-22 10:32:46,029 WARN [ActiveMQ
> InactivityMonitor Worker] [Transport] Transport Connection to:
> blockingQueue_28120594 failed:
> org.apache.activemq.transport.InactivityIOException: Channel was inactive
> 2016-04-22 10:33:30.988313500
> org.apache.activemq.transport.InactivityIOException: Channel was inactive (no
> connection attempt made) for too (>3) long: blockingQueue_21644517
> 2016-04-22 10:33:30.988637500 at
> org.apache.activemq.transport.AbstractInactivityMonitor$1$1.run(AbstractInactivityMonitor.java:91)
> 2016-04-22 10:33:30.988667500 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 2016-04-22 10:33:30.988689500 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 2016-04-22 10:33:30.988717500 at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-863) Network Health Check / ping list
[ https://issues.apache.org/jira/browse/ARTEMIS-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706431#comment-15706431 ] ASF GitHub Bot commented on ARTEMIS-863: Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/899 > Network Health Check / ping list > > > Key: ARTEMIS-863 > URL: https://issues.apache.org/jira/browse/ARTEMIS-863 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.6.0 > > > It should be possible to pass a network list of IPs the broker can ping on a > given interval, and decide if the broker should go down upon network failure. > This was done to provide a way to check network isolations on single node > backup replicated, but it could use to other scenarios and determine when to > shutdown a broker upon failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-863) Network Health Check / ping list
[ https://issues.apache.org/jira/browse/ARTEMIS-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706429#comment-15706429 ] ASF subversion and git services commented on ARTEMIS-863: - Commit 43634c098b1815bc6abe220b6e21b76bdbcb7856 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=43634c0 ] ARTEMIS-863 parsing spaces properly on network health addresses and avoiding loopback on configuration > Network Health Check / ping list > > > Key: ARTEMIS-863 > URL: https://issues.apache.org/jira/browse/ARTEMIS-863 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.6.0 > > > It should be possible to pass a network list of IPs the broker can ping on a > given interval, and decide if the broker should go down upon network failure. > This was done to provide a way to check network isolations on single node > backup replicated, but it could use to other scenarios and determine when to > shutdown a broker upon failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-863) Network Health Check / ping list
[ https://issues.apache.org/jira/browse/ARTEMIS-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706412#comment-15706412 ] ASF GitHub Bot commented on ARTEMIS-863: Github user jbertram commented on the issue: https://github.com/apache/activemq-artemis/pull/899 Looks good. > Network Health Check / ping list > > > Key: ARTEMIS-863 > URL: https://issues.apache.org/jira/browse/ARTEMIS-863 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.6.0 > > > It should be possible to pass a network list of IPs the broker can ping on a > given interval, and decide if the broker should go down upon network failure. > This was done to provide a way to check network isolations on single node > backup replicated, but it could use to other scenarios and determine when to > shutdown a broker upon failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-868) Lost connection to stomp over web socket
ma created ARTEMIS-868: -- Summary: Lost connection to stomp over web socket Key: ARTEMIS-868 URL: https://issues.apache.org/jira/browse/ARTEMIS-868 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker, Stomp Affects Versions: 1.5.0, 1.4.0 Environment: S.O: RHEL 7 Reporter: ma Priority: Critical Fix For: 1.6.0 I'm trying to communicate with artemis beta 1 broker using the stomp over websocket protocol. But I get the following error message: Whoops! Lost connection to ws: // localhost: 61614 To perform the communication I using the stompjs library indicated in the documentation of the artermis http://jmesnil.net/stomp-websocket/doc/ abaixo o log gerado pelo amq artemis: 15:59:28,348 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 15:59:28,369 INFO [org.apache.activemq.artemis.core.server] AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=false,journalDirectory=./data/journal,bindingsDirectory=./data/bindings,largeMessagesDirectory=./data/large-messages,pagingDirectory=./data/paging) 15:59:28,406 INFO [org.apache.activemq.artemis.core.server] AMQ221012: Using AIO Journal 15:59:28,471 INFO [org.apache.activemq.artemis.core.server] AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE 15:59:28,474 INFO [org.apache.activemq.artemis.core.server] AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP 15:59:28,475 INFO [org.apache.activemq.artemis.core.server] AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ 15:59:28,476 INFO [org.apache.activemq.artemis.core.server] AMQ221043: Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: MQTT 15:59:28,478 INFO [org.apache.activemq.artemis.core.server] AMQ221043: Protocol module found: [artemis-openwire-protocol]. Adding protocol support for: OPENWIRE 15:59:28,479 INFO [org.apache.activemq.artemis.core.server] AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP 15:59:29,078 INFO [org.apache.activemq.artemis.core.server] AMQ221003: Deploying queue jms.queue.Request 15:59:29,090 INFO [org.apache.activemq.artemis.core.server] AMQ221003: Deploying queue jms.queue.DLQ 15:59:29,093 INFO [org.apache.activemq.artemis.core.server] AMQ221003: Deploying queue jms.queue.ExpiryQueue 15:59:30,496 INFO [org.apache.activemq.artemis.core.server] AMQ221020: Started Acceptor at 0.0.0.0:61614 for protocols [STOMP] 15:59:30,502 INFO [org.apache.activemq.artemis.core.server] AMQ221020: Started Acceptor at 0.0.0.0:61616 for protocols [CORE,MQTT,AMQP,HORNETQ,STOMP,OPENWIRE] 15:59:30,506 INFO [org.apache.activemq.artemis.core.server] AMQ221020: Started Acceptor at 0.0.0.0:5445 for protocols [HORNETQ,STOMP] 15:59:30,510 INFO [org.apache.activemq.artemis.core.server] AMQ221020: Started Acceptor at 0.0.0.0:5672 for protocols [AMQP] 15:59:30,514 INFO [org.apache.activemq.artemis.core.server] AMQ221020: Started Acceptor at 0.0.0.0:1883 for protocols [MQTT] 15:59:30,517 INFO [org.apache.activemq.artemis.core.server] AMQ221020: Started Acceptor at 0.0.0.0:61613 for protocols [STOMP] 15:59:30,518 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live 15:59:30,518 INFO [org.apache.activemq.artemis.core.server] AMQ221001: Apache ActiveMQ Artemis Message Broker version 1.3.0.amq-75-redhat-1 [broker, nodeID=4464cd65-a783-11e6-8cb6-fa163e93081c] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. INFO | main | Initialized artemis-plugin plugin INFO | main | Initialized dispatch-hawtio-console plugin 15:59:32,416 INFO [org.apache.activemq.artemis] AMQ241001: HTTP Server started at http://0.0.0.0:8181 15:59:32,417 INFO [org.apache.activemq.artemis] AMQ241002: Artemis Jolokia REST API available at http://0.0.0.0:8181/jolokia 16:27:10,645 WARN [org.apache.activemq.artemis.core.server] AMQ222067: Connection failure has been detected: AMQ119014: Did not receive data from /10.52.209.93:6584 within the 20,000ms connection TTL. The connection will now be closed. [code=CONNECTION_TIMEDOUT] 16:27:20,649 WARN [org.apache.activemq.artemis.core.protocol.stomp] AMQ222068: connection closed org.apache.activemq.artemis.core.protocol.stomp.StompConnection@164d7a33 16:27:30,649 WARN [org.apache.activemq.artemis.core.protocol.stomp] AMQ222068: connection closed org.apache.activemq.artemis.core.protocol.stomp.StompConnection@164d7a33 16:27:40,650 WARN [org.apache.activemq.artemis.core.protocol.stomp] AMQ222068: connection closed org.apa
[jira] [Commented] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706288#comment-15706288
]
Christopher L. Shannon commented on AMQ-6521:
-
Soon, I plan on doing a release either this week or next week if no blocking
issues come up.
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.15.0, 5.14.2
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706229#comment-15706229
]
Carsten Hammer commented on AMQ-6521:
-
Great, I would like to try it out with the next release but I did not find a
planned release date for the 5.14.2 release in jira. Seems the Roadmap Gadget
in the Jira Dashboard is not used in ActiveMQ. Do you know when the next
release is available?
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.15.0, 5.14.2
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6523) 5.14.1 Upgrade causes Failed to browse Topic NullPointerException
[ https://issues.apache.org/jira/browse/AMQ-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706219#comment-15706219 ] Timothy Bish commented on AMQ-6523: --- This sort of support question is better directed to the users mailing list. > 5.14.1 Upgrade causes Failed to browse Topic NullPointerException > - > > Key: AMQ-6523 > URL: https://issues.apache.org/jira/browse/AMQ-6523 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.14.1 > Environment: Centos 5.5 >Reporter: jack patwork > > After upgrading a 4 node cluster from 5.9.1 to 5.14.1 I'm seeing my amq logs > spammed with 1000's of the following warnings. This was after shutting down > all 4 instances, deleting the db and restarting them. > It looks like the scheduler is stuck in a loop trying to deal with topics > that have been deleted. I'm just wondering where the scheduler has picked up > these tasks from given that the db was completely removed. > 2016-11-29 15:14:55,555 | WARN | Failed to browse Topic: my.custom.topic.123 > | org.apache.activemq.broker.region.Topic | ActiveMQ Broker[myBrokerName] > Scheduler > java.lang.NullPointerException > at > org.apache.activemq.broker.region.policy.FixedCountSubscriptionRecoveryPolicy.browse(FixedCountSubscriptionRecoveryPolicy.java:102)[activemq-broker-5.14.1.jar:5.14.1] > at > org.apache.activemq.broker.region.policy.RetainedMessageSubscriptionRecoveryPolicy.browse(RetainedMessageSubscriptionRecoveryPolicy.java:111)[activemq-broker-5.14.1.jar:5.14.1] > at > org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:674)[activemq-broker-5.14.1.jar:5.14.1] > at > org.apache.activemq.broker.region.Topic.access$100(Topic.java:69)[activemq-broker-5.14.1.jar:5.14.1] > at > org.apache.activemq.broker.region.Topic$6.run(Topic.java:780)[activemq-broker-5.14.1.jar:5.14.1] > at > org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)[activemq-client-5.14.1.jar:5.14.1] > at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_101] > at java.util.TimerThread.run(Timer.java:505)[:1.7.0_101] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-867) make quorum vote mechanism pluggable
Andy Taylor created ARTEMIS-867: --- Summary: make quorum vote mechanism pluggable Key: ARTEMIS-867 URL: https://issues.apache.org/jira/browse/ARTEMIS-867 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Reporter: Andy Taylor Assignee: Andy Taylor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6523) 5.14.1 Upgrade causes Failed to browse Topic NullPointerException
jack patwork created AMQ-6523: - Summary: 5.14.1 Upgrade causes Failed to browse Topic NullPointerException Key: AMQ-6523 URL: https://issues.apache.org/jira/browse/AMQ-6523 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.14.1 Environment: Centos 5.5 Reporter: jack patwork After upgrading a 4 node cluster from 5.9.1 to 5.14.1 I'm seeing my amq logs spammed with 1000's of the following warnings. This was after shutting down all 4 instances, deleting the db and restarting them. It looks like the scheduler is stuck in a loop trying to deal with topics that have been deleted. I'm just wondering where the scheduler has picked up these tasks from given that the db was completely removed. 2016-11-29 15:14:55,555 | WARN | Failed to browse Topic: my.custom.topic.123 | org.apache.activemq.broker.region.Topic | ActiveMQ Broker[myBrokerName] Scheduler java.lang.NullPointerException at org.apache.activemq.broker.region.policy.FixedCountSubscriptionRecoveryPolicy.browse(FixedCountSubscriptionRecoveryPolicy.java:102)[activemq-broker-5.14.1.jar:5.14.1] at org.apache.activemq.broker.region.policy.RetainedMessageSubscriptionRecoveryPolicy.browse(RetainedMessageSubscriptionRecoveryPolicy.java:111)[activemq-broker-5.14.1.jar:5.14.1] at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:674)[activemq-broker-5.14.1.jar:5.14.1] at org.apache.activemq.broker.region.Topic.access$100(Topic.java:69)[activemq-broker-5.14.1.jar:5.14.1] at org.apache.activemq.broker.region.Topic$6.run(Topic.java:780)[activemq-broker-5.14.1.jar:5.14.1] at org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)[activemq-client-5.14.1.jar:5.14.1] at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_101] at java.util.TimerThread.run(Timer.java:505)[:1.7.0_101] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)
[
https://issues.apache.org/jira/browse/AMQ-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706080#comment-15706080
]
William Crowell commented on AMQ-6441:
--
I would love to take this on, but I am swamped.
> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave
> configuration (KahaDB). I've set everything up and mounted the EFS on both
> EC2 instances.
> When I check the disk free stats I get 8 exabytes for the shared file system:
> {code}
> $ df -h
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory:
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to
> maximum available disk space: -8796093022207 mb
> Store limit is -8796093022207 mb, whilst the max journal file size for the
> store is: 32 mb, the store will not accept any data when used.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)
[
https://issues.apache.org/jira/browse/AMQ-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706052#comment-15706052
]
Claus Ibsen commented on AMQ-6441:
--
Is anyone working on implementing the last suggestions from Christopher about
that flag to turn on | off.
> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave
> configuration (KahaDB). I've set everything up and mounted the EFS on both
> EC2 instances.
> When I check the disk free stats I get 8 exabytes for the shared file system:
> {code}
> $ df -h
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory:
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to
> maximum available disk space: -8796093022207 mb
> Store limit is -8796093022207 mb, whilst the max journal file size for the
> store is: 32 mb, the store will not accept any data when used.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)
[
https://issues.apache.org/jira/browse/AMQ-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706074#comment-15706074
]
Christopher L. Shannon commented on AMQ-6441:
-
I don't think anything has been done since the original PR. I haven't gotten
around to it yet but if no one else does then it's something I can work on for
a future 5.14.x or 5.15.0 release.
> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave
> configuration (KahaDB). I've set everything up and mounted the EFS on both
> EC2 instances.
> When I check the disk free stats I get 8 exabytes for the shared file system:
> {code}
> $ df -h
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory:
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to
> maximum available disk space: -8796093022207 mb
> Store limit is -8796093022207 mb, whilst the max journal file size for the
> store is: 32 mb, the store will not accept any data when used.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-5659) Add safety measure against infinite loop when store exception prevents message removal
[
https://issues.apache.org/jira/browse/AMQ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved AMQ-5659.
--
Resolution: Fixed
Assignee: Claus Ibsen
Fix Version/s: 5.15.0
Thanks for the patch
> Add safety measure against infinite loop when store exception prevents
> message removal
> --
>
> Key: AMQ-5659
> URL: https://issues.apache.org/jira/browse/AMQ-5659
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.7.0
> Environment: ServiceMix 4.5.3
>Reporter: metatech
>Assignee: Claus Ibsen
> Fix For: 5.15.0
>
> Attachments: purge_queue_abort_loop_v3.patch
>
>
> When the broker is configured with a database store, the "purge" operation
> enters an infinite loop when the message removal operation fails, for
> instance when the broker datasource is being restarted (see example stack
> trace below).
> Here is a patch which adds a safety measure, in case the "dequeue" count of
> the queue does not increase between 2 messages removal operations. The check
> is not garanteed to detect the problem on the next iteration, because a
> business consumer might also be dequeuing messages from the queue. But the
> "purge" is probably much faster than the business consumer, so if it fails to
> remove 2 messages in a row, it is enough to detect the problem and abort the
> infinite loop.
> {code}
> 2015-03-05 15:38:30,353 | WARN | 14571659-2202099 | |
> JDBCPersistenceAdapter | Could not get JDBC connection: Data source
> is closed
> java.sql.SQLException: Data source is closed
> at
> org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1362)
> at
> org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
> at
> org.apache.activemq.store.jdbc.TransactionContext.getConnection(TransactionContext.java:58)
> at
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.getStoreSequenceId(DefaultJDBCAdapter.java:285)
> at
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.getStoreSequenceIdForMessageId(JDBCPersistenceAdapter.java:787)
> at
> org.apache.activemq.store.jdbc.JDBCMessageStore.removeMessage(JDBCMessageStore.java:194)
> at
> org.apache.activemq.store.memory.MemoryTransactionStore.removeMessage(MemoryTransactionStore.java:358)
> at
> org.apache.activemq.store.memory.MemoryTransactionStore$1.removeAsyncMessage(MemoryTransactionStore.java:166)
> at org.apache.activemq.broker.region.Queue.acknowledge(Queue.java:846)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1602)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1594)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1579)
> at org.apache.activemq.broker.region.Queue.purge(Queue.java:1158)
> at org.apache.activemq.broker.jmx.QueueView.purge(QueueView.java:54)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5659) Add safety measure against infinite loop when store exception prevents message removal
[
https://issues.apache.org/jira/browse/AMQ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706021#comment-15706021
]
ASF GitHub Bot commented on AMQ-5659:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq/pull/72
> Add safety measure against infinite loop when store exception prevents
> message removal
> --
>
> Key: AMQ-5659
> URL: https://issues.apache.org/jira/browse/AMQ-5659
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.7.0
> Environment: ServiceMix 4.5.3
>Reporter: metatech
> Fix For: 5.15.0
>
> Attachments: purge_queue_abort_loop_v3.patch
>
>
> When the broker is configured with a database store, the "purge" operation
> enters an infinite loop when the message removal operation fails, for
> instance when the broker datasource is being restarted (see example stack
> trace below).
> Here is a patch which adds a safety measure, in case the "dequeue" count of
> the queue does not increase between 2 messages removal operations. The check
> is not garanteed to detect the problem on the next iteration, because a
> business consumer might also be dequeuing messages from the queue. But the
> "purge" is probably much faster than the business consumer, so if it fails to
> remove 2 messages in a row, it is enough to detect the problem and abort the
> infinite loop.
> {code}
> 2015-03-05 15:38:30,353 | WARN | 14571659-2202099 | |
> JDBCPersistenceAdapter | Could not get JDBC connection: Data source
> is closed
> java.sql.SQLException: Data source is closed
> at
> org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1362)
> at
> org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
> at
> org.apache.activemq.store.jdbc.TransactionContext.getConnection(TransactionContext.java:58)
> at
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.getStoreSequenceId(DefaultJDBCAdapter.java:285)
> at
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.getStoreSequenceIdForMessageId(JDBCPersistenceAdapter.java:787)
> at
> org.apache.activemq.store.jdbc.JDBCMessageStore.removeMessage(JDBCMessageStore.java:194)
> at
> org.apache.activemq.store.memory.MemoryTransactionStore.removeMessage(MemoryTransactionStore.java:358)
> at
> org.apache.activemq.store.memory.MemoryTransactionStore$1.removeAsyncMessage(MemoryTransactionStore.java:166)
> at org.apache.activemq.broker.region.Queue.acknowledge(Queue.java:846)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1602)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1594)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1579)
> at org.apache.activemq.broker.region.Queue.purge(Queue.java:1158)
> at org.apache.activemq.broker.jmx.QueueView.purge(QueueView.java:54)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5659) Add safety measure against infinite loop when store exception prevents message removal
[
https://issues.apache.org/jira/browse/AMQ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706018#comment-15706018
]
ASF subversion and git services commented on AMQ-5659:
--
Commit 78492febc858ff06c1ef42e49cdfefc39a6855fb in activemq's branch
refs/heads/master from [~davsclaus]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=78492fe ]
AMQ-5659: Add safety measure against infinite loop when store exception
prevents message removal. Thanks to metatechbe for the patch. This fixes #72.
> Add safety measure against infinite loop when store exception prevents
> message removal
> --
>
> Key: AMQ-5659
> URL: https://issues.apache.org/jira/browse/AMQ-5659
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.7.0
> Environment: ServiceMix 4.5.3
>Reporter: metatech
> Attachments: purge_queue_abort_loop_v3.patch
>
>
> When the broker is configured with a database store, the "purge" operation
> enters an infinite loop when the message removal operation fails, for
> instance when the broker datasource is being restarted (see example stack
> trace below).
> Here is a patch which adds a safety measure, in case the "dequeue" count of
> the queue does not increase between 2 messages removal operations. The check
> is not garanteed to detect the problem on the next iteration, because a
> business consumer might also be dequeuing messages from the queue. But the
> "purge" is probably much faster than the business consumer, so if it fails to
> remove 2 messages in a row, it is enough to detect the problem and abort the
> infinite loop.
> {code}
> 2015-03-05 15:38:30,353 | WARN | 14571659-2202099 | |
> JDBCPersistenceAdapter | Could not get JDBC connection: Data source
> is closed
> java.sql.SQLException: Data source is closed
> at
> org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1362)
> at
> org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
> at
> org.apache.activemq.store.jdbc.TransactionContext.getConnection(TransactionContext.java:58)
> at
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.getStoreSequenceId(DefaultJDBCAdapter.java:285)
> at
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.getStoreSequenceIdForMessageId(JDBCPersistenceAdapter.java:787)
> at
> org.apache.activemq.store.jdbc.JDBCMessageStore.removeMessage(JDBCMessageStore.java:194)
> at
> org.apache.activemq.store.memory.MemoryTransactionStore.removeMessage(MemoryTransactionStore.java:358)
> at
> org.apache.activemq.store.memory.MemoryTransactionStore$1.removeAsyncMessage(MemoryTransactionStore.java:166)
> at org.apache.activemq.broker.region.Queue.acknowledge(Queue.java:846)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1602)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1594)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1579)
> at org.apache.activemq.broker.region.Queue.purge(Queue.java:1158)
> at org.apache.activemq.broker.jmx.QueueView.purge(QueueView.java:54)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5939) ActiveMQ REST GET request is always encoded in ISO-8859-1
[ https://issues.apache.org/jira/browse/AMQ-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705978#comment-15705978 ] ASF GitHub Bot commented on AMQ-5939: - Github user asfgit closed the pull request at: https://github.com/apache/activemq/pull/140 > ActiveMQ REST GET request is always encoded in ISO-8859-1 > - > > Key: AMQ-5939 > URL: https://issues.apache.org/jira/browse/AMQ-5939 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.12.0 >Reporter: Kirill Dubovikov >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 5.15.0 > > > ActiveMQ REST protocol does not support encodings other than ISO-8859-1. > 1) response.setContentType is called after response.getWriter - this > contradicts servlet specification, so setContentType does not work at all > 2) Content-Type header for the GET response is hardcoded inside > MessageServlet class > I've changed the class so that Content-Type header is being read from > request. This way users now can specify message body encoding through > Content-Type header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-5976) Filter queues by name in admin webconsole
[ https://issues.apache.org/jira/browse/AMQ-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved AMQ-5976. -- Resolution: Fixed Assignee: Claus Ibsen Fix Version/s: (was: 5.11.2) (was: 5.10.2) (was: 5.9.1) 5.15.0 Thanks for the patch. > Filter queues by name in admin webconsole > - > > Key: AMQ-5976 > URL: https://issues.apache.org/jira/browse/AMQ-5976 > Project: ActiveMQ > Issue Type: Improvement > Components: webconsole >Affects Versions: 5.9.1, 5.10.2, 5.11.2 > Environment: Tested on Linux Ubuntu >Reporter: Francois Chartier >Assignee: Claus Ibsen > Labels: easyfix, patch > Fix For: 5.15.0 > > Attachments: queues.jsp, queues.jsp_AMQ5976.diff > > > When the number of queues in the broker gets somewhat large, I found that the > queues list in admin webconsole becomes somewhat cumbersome, especially if > one wants to monitor some queues. > I wrote a simple filter for this page (using only JSP/HTML and get method), > enabling to filter the queues by queue name. No impact on the server (all > queues are still queried), it just filters out the result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5976) Filter queues by name in admin webconsole
[ https://issues.apache.org/jira/browse/AMQ-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705973#comment-15705973 ] ASF GitHub Bot commented on AMQ-5976: - Github user asfgit closed the pull request at: https://github.com/apache/activemq/pull/144 > Filter queues by name in admin webconsole > - > > Key: AMQ-5976 > URL: https://issues.apache.org/jira/browse/AMQ-5976 > Project: ActiveMQ > Issue Type: Improvement > Components: webconsole >Affects Versions: 5.9.1, 5.10.2, 5.11.2 > Environment: Tested on Linux Ubuntu >Reporter: Francois Chartier > Labels: easyfix, patch > Fix For: 5.15.0 > > Attachments: queues.jsp, queues.jsp_AMQ5976.diff > > > When the number of queues in the broker gets somewhat large, I found that the > queues list in admin webconsole becomes somewhat cumbersome, especially if > one wants to monitor some queues. > I wrote a simple filter for this page (using only JSP/HTML and get method), > enabling to filter the queues by queue name. No impact on the server (all > queues are still queried), it just filters out the result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5976) Filter queues by name in admin webconsole
[ https://issues.apache.org/jira/browse/AMQ-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705970#comment-15705970 ] ASF subversion and git services commented on AMQ-5976: -- Commit 0b767fcb0c622810c01e54bd51bc9680e36f81f5 in activemq's branch refs/heads/master from [~davsclaus] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=0b767fc ] AMQ-5976: Filter queues by name in admin webconsole. Thanks to Francois Chartier for the patch. This closes #144. > Filter queues by name in admin webconsole > - > > Key: AMQ-5976 > URL: https://issues.apache.org/jira/browse/AMQ-5976 > Project: ActiveMQ > Issue Type: Improvement > Components: webconsole >Affects Versions: 5.9.1, 5.10.2, 5.11.2 > Environment: Tested on Linux Ubuntu >Reporter: Francois Chartier > Labels: easyfix, patch > Fix For: 5.15.0 > > Attachments: queues.jsp, queues.jsp_AMQ5976.diff > > > When the number of queues in the broker gets somewhat large, I found that the > queues list in admin webconsole becomes somewhat cumbersome, especially if > one wants to monitor some queues. > I wrote a simple filter for this page (using only JSP/HTML and get method), > enabling to filter the queues by queue name. No impact on the server (all > queues are still queried), it just filters out the result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5939) ActiveMQ REST GET request is always encoded in ISO-8859-1
[ https://issues.apache.org/jira/browse/AMQ-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705834#comment-15705834 ] ASF subversion and git services commented on AMQ-5939: -- Commit f888cc2729832c6c71f0da9b5586d731e7a41648 in activemq's branch refs/heads/master from [~davsclaus] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=f888cc2 ] AMQ-5939: ActiveMQ REST GET request is always encoded in ISO-8859-1. Thanks to Kirill Dubovikov for the patch. This fixes 140. > ActiveMQ REST GET request is always encoded in ISO-8859-1 > - > > Key: AMQ-5939 > URL: https://issues.apache.org/jira/browse/AMQ-5939 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.12.0 >Reporter: Kirill Dubovikov >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 5.15.0 > > > ActiveMQ REST protocol does not support encodings other than ISO-8859-1. > 1) response.setContentType is called after response.getWriter - this > contradicts servlet specification, so setContentType does not work at all > 2) Content-Type header for the GET response is hardcoded inside > MessageServlet class > I've changed the class so that Content-Type header is being read from > request. This way users now can specify message body encoding through > Content-Type header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-5939) ActiveMQ REST GET request is always encoded in ISO-8859-1
[ https://issues.apache.org/jira/browse/AMQ-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved AMQ-5939. -- Resolution: Fixed Fix Version/s: 5.15.0 Thanks for the PR > ActiveMQ REST GET request is always encoded in ISO-8859-1 > - > > Key: AMQ-5939 > URL: https://issues.apache.org/jira/browse/AMQ-5939 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.12.0 >Reporter: Kirill Dubovikov >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 5.15.0 > > > ActiveMQ REST protocol does not support encodings other than ISO-8859-1. > 1) response.setContentType is called after response.getWriter - this > contradicts servlet specification, so setContentType does not work at all > 2) Content-Type header for the GET response is hardcoded inside > MessageServlet class > I've changed the class so that Content-Type header is being read from > request. This way users now can specify message body encoding through > Content-Type header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5859) Reconnection attempt logic seems wrong in JmsConnector#doInitializeConnection
[
https://issues.apache.org/jira/browse/AMQ-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705821#comment-15705821
]
ASF GitHub Bot commented on AMQ-5859:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq/pull/122
> Reconnection attempt logic seems wrong in JmsConnector#doInitializeConnection
> -
>
> Key: AMQ-5859
> URL: https://issues.apache.org/jira/browse/AMQ-5859
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.10.2, 5.11.1
>Reporter: Benoit Wiart
>Priority: Critical
> Fix For: 5.12.0
>
> Attachments:
> 0001-AMQ-5859-Reconnection-attempt-logic-seems-wrong-in-J.patch
>
>
> the reconnection attempts logic based on the reconnection policy seems wrong.
> In JmsConnector#doInitializeConnection the loop trying to reconnect to the
> foreign broker only execute once due to the erroneous test in the while
> {code}
> while (maxRetries < ++attempt && !connectionSerivce.isTerminating());
> {code}
> should be
> {code}
> while (maxRetries > ++attempt && !connectionSerivce.isTerminating());
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-5796) Incorrect Task Usage mentioned for amq browse command for the msgsel
[
https://issues.apache.org/jira/browse/AMQ-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved AMQ-5796.
--
Resolution: Fixed
Assignee: Claus Ibsen
Fix Version/s: 5.15.0
Thanks for the patch
> Incorrect Task Usage mentioned for amq browse command for the msgsel
>
>
> Key: AMQ-5796
> URL: https://issues.apache.org/jira/browse/AMQ-5796
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.11.0, 5.11.1
> Environment: All
>Reporter: JaySenSharma
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 5.15.0
>
>
> - The *"megsel"* usage help mentioned in the activemq browse command does not
> put the message selector value in the Double quatation mark which is causing
> the users following error.
> {code}
> [jsensharma@localhost bin]$ cd apache-activemq-5.11.1/bin
> [jsensharma@localhost bin]$ ./activemq-admin browse --amqurl
> tcp://localhost:61616 --msgsel JMSMessageID='*:1' FOO.BAR
> ERROR: java.lang.RuntimeException: Failed to execute browse task. Reason:
> javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> java.lang.RuntimeException: Failed to execute browse task. Reason:
> javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:155)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> ERROR: java.lang.Exception: javax.jms.InvalidSelectorException:
> (JMSMessageID=*:1)
> java.lang.Exception: javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:156)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> Caused by: javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.selector.SelectorParser.parse(SelectorParser.java:88)
> at
> org.apache.activemq.selector.SelectorParser.parse(SelectorParser.java:58)
> at
> org.apache.activemq.ActiveMQQueueBrowser.(ActiveMQQueueBrowser.java:80)
> at
> org.apache.activemq.ActiveMQSession.createBrowser(ActiveMQSession.java:1449)
> at
> org.apache.activemq.console.filter.AmqMessagesQueryFilter.queryMessages(AmqMessagesQueryFilter.java:104)
> at
> org.apache.activemq.console.filter.AmqMessagesQueryFilter.query(AmqMessagesQueryFilter.java:86)
> at
> org.apache.activemq.console.filter.WildcardTransformFilter.query(WildcardTransformFilter.java:60)
> at
> org.apache.activemq.console.util.AmqMessagesUtil.getMessages(AmqMessagesUtil.java:60)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:142)
> ... 10 more
> Caused by: org.apache.activemq.selector.ParseException: Parse error at line
> 1, column 15. Encountered: *
> at
> org.apache.activemq.selector.SelectorParser.generateParseException(SelectorParser.java:1313)
> at
> org.apache.activemq.selector.SelectorParser.jj_consume_token(SelectorParser.java:1261)
> at
> org.apache.activemq.selector.SelectorParser.unaryExpr(SelectorParser.java:474)
> at
> org.apache.activemq.selector.SelectorParser.multExpr(SelectorParser.java:391)
> at
>
[jira] [Commented] (AMQ-5796) Incorrect Task Usage mentioned for amq browse command for the msgsel
[
https://issues.apache.org/jira/browse/AMQ-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705802#comment-15705802
]
ASF subversion and git services commented on AMQ-5796:
--
Commit e6fa7353252e57f4e573bcd3d00b82b76c2fe0be in activemq's branch
refs/heads/master from [~davsclaus]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=e6fa735 ]
AMQ-5796: Incorrect Task Usage mentioned for amq browse command. Thanks to Jay
SenSharma for the patch. This fixes #104.
> Incorrect Task Usage mentioned for amq browse command for the msgsel
>
>
> Key: AMQ-5796
> URL: https://issues.apache.org/jira/browse/AMQ-5796
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.11.0, 5.11.1
> Environment: All
>Reporter: JaySenSharma
>
> - The *"megsel"* usage help mentioned in the activemq browse command does not
> put the message selector value in the Double quatation mark which is causing
> the users following error.
> {code}
> [jsensharma@localhost bin]$ cd apache-activemq-5.11.1/bin
> [jsensharma@localhost bin]$ ./activemq-admin browse --amqurl
> tcp://localhost:61616 --msgsel JMSMessageID='*:1' FOO.BAR
> ERROR: java.lang.RuntimeException: Failed to execute browse task. Reason:
> javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> java.lang.RuntimeException: Failed to execute browse task. Reason:
> javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:155)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> ERROR: java.lang.Exception: javax.jms.InvalidSelectorException:
> (JMSMessageID=*:1)
> java.lang.Exception: javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:156)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> Caused by: javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.selector.SelectorParser.parse(SelectorParser.java:88)
> at
> org.apache.activemq.selector.SelectorParser.parse(SelectorParser.java:58)
> at
> org.apache.activemq.ActiveMQQueueBrowser.(ActiveMQQueueBrowser.java:80)
> at
> org.apache.activemq.ActiveMQSession.createBrowser(ActiveMQSession.java:1449)
> at
> org.apache.activemq.console.filter.AmqMessagesQueryFilter.queryMessages(AmqMessagesQueryFilter.java:104)
> at
> org.apache.activemq.console.filter.AmqMessagesQueryFilter.query(AmqMessagesQueryFilter.java:86)
> at
> org.apache.activemq.console.filter.WildcardTransformFilter.query(WildcardTransformFilter.java:60)
> at
> org.apache.activemq.console.util.AmqMessagesUtil.getMessages(AmqMessagesUtil.java:60)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:142)
> ... 10 more
> Caused by: org.apache.activemq.selector.ParseException: Parse error at line
> 1, column 15. Encountered: *
> at
> org.apache.activemq.selector.SelectorParser.generateParseException(SelectorParser.java:1313)
> at
> org.apache.activemq.selector.SelectorParser.jj_consume_token(SelectorParser.java:1261)
>
[jira] [Updated] (AMQ-5796) Incorrect Task Usage mentioned for amq browse command for the msgsel
[
https://issues.apache.org/jira/browse/AMQ-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated AMQ-5796:
-
Priority: Trivial (was: Major)
> Incorrect Task Usage mentioned for amq browse command for the msgsel
>
>
> Key: AMQ-5796
> URL: https://issues.apache.org/jira/browse/AMQ-5796
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.11.0, 5.11.1
> Environment: All
>Reporter: JaySenSharma
>Priority: Trivial
> Fix For: 5.15.0
>
>
> - The *"megsel"* usage help mentioned in the activemq browse command does not
> put the message selector value in the Double quatation mark which is causing
> the users following error.
> {code}
> [jsensharma@localhost bin]$ cd apache-activemq-5.11.1/bin
> [jsensharma@localhost bin]$ ./activemq-admin browse --amqurl
> tcp://localhost:61616 --msgsel JMSMessageID='*:1' FOO.BAR
> ERROR: java.lang.RuntimeException: Failed to execute browse task. Reason:
> javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> java.lang.RuntimeException: Failed to execute browse task. Reason:
> javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:155)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> ERROR: java.lang.Exception: javax.jms.InvalidSelectorException:
> (JMSMessageID=*:1)
> java.lang.Exception: javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:156)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> Caused by: javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.selector.SelectorParser.parse(SelectorParser.java:88)
> at
> org.apache.activemq.selector.SelectorParser.parse(SelectorParser.java:58)
> at
> org.apache.activemq.ActiveMQQueueBrowser.(ActiveMQQueueBrowser.java:80)
> at
> org.apache.activemq.ActiveMQSession.createBrowser(ActiveMQSession.java:1449)
> at
> org.apache.activemq.console.filter.AmqMessagesQueryFilter.queryMessages(AmqMessagesQueryFilter.java:104)
> at
> org.apache.activemq.console.filter.AmqMessagesQueryFilter.query(AmqMessagesQueryFilter.java:86)
> at
> org.apache.activemq.console.filter.WildcardTransformFilter.query(WildcardTransformFilter.java:60)
> at
> org.apache.activemq.console.util.AmqMessagesUtil.getMessages(AmqMessagesUtil.java:60)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:142)
> ... 10 more
> Caused by: org.apache.activemq.selector.ParseException: Parse error at line
> 1, column 15. Encountered: *
> at
> org.apache.activemq.selector.SelectorParser.generateParseException(SelectorParser.java:1313)
> at
> org.apache.activemq.selector.SelectorParser.jj_consume_token(SelectorParser.java:1261)
> at
> org.apache.activemq.selector.SelectorParser.unaryExpr(SelectorParser.java:474)
> at
> org.apache.activemq.selector.SelectorParser.multExpr(SelectorParser.java:391)
> at
> org.apache.activemq.selector.SelectorParser.addExpression(SelectorParser.java:360)
> at
> org.apac
[jira] [Commented] (AMQ-5796) Incorrect Task Usage mentioned for amq browse command for the msgsel
[
https://issues.apache.org/jira/browse/AMQ-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705805#comment-15705805
]
ASF GitHub Bot commented on AMQ-5796:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq/pull/104
> Incorrect Task Usage mentioned for amq browse command for the msgsel
>
>
> Key: AMQ-5796
> URL: https://issues.apache.org/jira/browse/AMQ-5796
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.11.0, 5.11.1
> Environment: All
>Reporter: JaySenSharma
>
> - The *"megsel"* usage help mentioned in the activemq browse command does not
> put the message selector value in the Double quatation mark which is causing
> the users following error.
> {code}
> [jsensharma@localhost bin]$ cd apache-activemq-5.11.1/bin
> [jsensharma@localhost bin]$ ./activemq-admin browse --amqurl
> tcp://localhost:61616 --msgsel JMSMessageID='*:1' FOO.BAR
> ERROR: java.lang.RuntimeException: Failed to execute browse task. Reason:
> javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> java.lang.RuntimeException: Failed to execute browse task. Reason:
> javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:155)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> ERROR: java.lang.Exception: javax.jms.InvalidSelectorException:
> (JMSMessageID=*:1)
> java.lang.Exception: javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:156)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> Caused by: javax.jms.InvalidSelectorException: (JMSMessageID=*:1)
> at
> org.apache.activemq.selector.SelectorParser.parse(SelectorParser.java:88)
> at
> org.apache.activemq.selector.SelectorParser.parse(SelectorParser.java:58)
> at
> org.apache.activemq.ActiveMQQueueBrowser.(ActiveMQQueueBrowser.java:80)
> at
> org.apache.activemq.ActiveMQSession.createBrowser(ActiveMQSession.java:1449)
> at
> org.apache.activemq.console.filter.AmqMessagesQueryFilter.queryMessages(AmqMessagesQueryFilter.java:104)
> at
> org.apache.activemq.console.filter.AmqMessagesQueryFilter.query(AmqMessagesQueryFilter.java:86)
> at
> org.apache.activemq.console.filter.WildcardTransformFilter.query(WildcardTransformFilter.java:60)
> at
> org.apache.activemq.console.util.AmqMessagesUtil.getMessages(AmqMessagesUtil.java:60)
> at
> org.apache.activemq.console.command.AmqBrowseCommand.runTask(AmqBrowseCommand.java:142)
> ... 10 more
> Caused by: org.apache.activemq.selector.ParseException: Parse error at line
> 1, column 15. Encountered: *
> at
> org.apache.activemq.selector.SelectorParser.generateParseException(SelectorParser.java:1313)
> at
> org.apache.activemq.selector.SelectorParser.jj_consume_token(SelectorParser.java:1261)
> at
> org.apache.activemq.selector.SelectorParser.unaryExpr(SelectorParser.java:474)
> at
> org.apache.activemq.selector.SelectorParser.multExpr(SelectorParser.java:391)
> at
> org.apache.activemq.selector.SelectorParser
[jira] [Resolved] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon resolved AMQ-6521.
-
Resolution: Fixed
I was able to make this work for 9.3 by using reflection to search for the
correct GzipHandler. It will go into the 5.14.2 release.
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.15.0, 5.14.2
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-6521:
Fix Version/s: 5.14.2
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.15.0, 5.14.2
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705789#comment-15705789
]
ASF subversion and git services commented on AMQ-6521:
--
Commit 4cdd188ef22524391d8801e865a4c9eed8c8eb06 in activemq's branch
refs/heads/activemq-5.14.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=4cdd188 ]
https://issues.apache.org/jira/browse/AMQ-6521
Adding support for Jetty 9.3 by re-adding in the logic to dynamically
load the correct GzipHandler depending on the version
(cherry picked from commit 80f46a80560b2b2ed9fb418c33df75136bc3dc52)
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.15.0
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705787#comment-15705787
]
ASF subversion and git services commented on AMQ-6521:
--
Commit 80f46a80560b2b2ed9fb418c33df75136bc3dc52 in activemq's branch
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=80f46a8 ]
https://issues.apache.org/jira/browse/AMQ-6521
Adding support for Jetty 9.3 by re-adding in the logic to dynamically
load the correct GzipHandler depending on the version
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.15.0
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5654) Allow ActiveMQ authentication on server side for REST/Ajax clients.
[
https://issues.apache.org/jira/browse/AMQ-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705764#comment-15705764
]
ASF GitHub Bot commented on AMQ-5654:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq/pull/70
> Allow ActiveMQ authentication on server side for REST/Ajax clients.
> ---
>
> Key: AMQ-5654
> URL: https://issues.apache.org/jira/browse/AMQ-5654
> Project: ActiveMQ
> Issue Type: Improvement
>Affects Versions: 5.9.1, 5.11.1
>Reporter: Geert Pante
> Fix For: 5.15.0
>
>
> Currently, for REST or Ajax clients to connect to a secured ActiveMQ, the
> client side needs to send the activemq credentials over HTTP.
> It should be possible to use a different authentication mechanism for the
> HTTP connection, and let the servlet use a system account to connect to
> ActiveMQ.
> Additionally, it would be great to allow ${} placeholders in the servlet
> context parameters, which could be resolved by system properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5654) Allow ActiveMQ authentication on server side for REST/Ajax clients.
[
https://issues.apache.org/jira/browse/AMQ-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705760#comment-15705760
]
ASF subversion and git services commented on AMQ-5654:
--
Commit 7fe862caf4e9f6b57d8265bf8ca1d3d97f2be99a in activemq's branch
refs/heads/master from [~davsclaus]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=7fe862c ]
AMQ-5654 Allow ActiveMQ authentication on server side for REST/Ajax clients.
Thanks to Geert Pante for the patch. This fixes #70.
> Allow ActiveMQ authentication on server side for REST/Ajax clients.
> ---
>
> Key: AMQ-5654
> URL: https://issues.apache.org/jira/browse/AMQ-5654
> Project: ActiveMQ
> Issue Type: Improvement
>Affects Versions: 5.9.1, 5.11.1
>Reporter: Geert Pante
> Fix For: 5.15.0
>
>
> Currently, for REST or Ajax clients to connect to a secured ActiveMQ, the
> client side needs to send the activemq credentials over HTTP.
> It should be possible to use a different authentication mechanism for the
> HTTP connection, and let the servlet use a system account to connect to
> ActiveMQ.
> Additionally, it would be great to allow ${} placeholders in the servlet
> context parameters, which could be resolved by system properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-5654) Allow ActiveMQ authentication on server side for REST/Ajax clients.
[
https://issues.apache.org/jira/browse/AMQ-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved AMQ-5654.
--
Resolution: Fixed
Assignee: Claus Ibsen
Fix Version/s: 5.15.0
Thanks for the PR. Sorry for the late merge.
> Allow ActiveMQ authentication on server side for REST/Ajax clients.
> ---
>
> Key: AMQ-5654
> URL: https://issues.apache.org/jira/browse/AMQ-5654
> Project: ActiveMQ
> Issue Type: Improvement
>Affects Versions: 5.9.1, 5.11.1
>Reporter: Geert Pante
>Assignee: Claus Ibsen
> Fix For: 5.15.0
>
>
> Currently, for REST or Ajax clients to connect to a secured ActiveMQ, the
> client side needs to send the activemq credentials over HTTP.
> It should be possible to use a different authentication mechanism for the
> HTTP connection, and let the servlet use a system account to connect to
> ActiveMQ.
> Additionally, it would be great to allow ${} placeholders in the servlet
> context parameters, which could be resolved by system properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5714) Issue with pathCanonical() method within activemq startup for installation paths that consist of directories with a single character or 2 characters
[
https://issues.apache.org/jira/browse/AMQ-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705765#comment-15705765
]
ASF GitHub Bot commented on AMQ-5714:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq/pull/83
> Issue with pathCanonical() method within activemq startup for installation
> paths that consist of directories with a single character or 2 characters
>
>
> Key: AMQ-5714
> URL: https://issues.apache.org/jira/browse/AMQ-5714
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: James Spurin
>Priority: Minor
> Fix For: 5.12.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The pathCanonical method does not work as expected for directories that
> contain either single characters or 2 characters. This is caused by the
> following entry -
> {noformat}
> echo "${dst}" | sed -e 's#//#/#g' -e 's#/./#/#g' -e 's#/[^/]*/../#/#g'
> {noformat}
> This can be resolved with the following changes -
> {noformat}
> echo "${dst}" | sed -e 's#//#/#g' -e 's#/\./#/#g' -e 's#/[^/]*/\.\./#/#g'
> {noformat}
> Example, before and after -
> {noformat}
> # echo /1/2/3/4/11/22/33/44/.././x | sed -e 's#//#/#g' -e 's#/./#/#g' -e
> 's#/[^/]*/../#/#g'
> /2/22/../x
> # echo /1/2/3/4/11/22/33/44/.././x | sed -e 's#//#/#g' -e 's#/\./#/#g' -e
> 's#/[^/]*/\.\./#/#g'
> /1/2/3/4/11/22/33/x
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5645) CronParser.getNextScheduledTime() for the first day of every month
[
https://issues.apache.org/jira/browse/AMQ-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705737#comment-15705737
]
ASF GitHub Bot commented on AMQ-5645:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq/pull/69
> CronParser.getNextScheduledTime() for the first day of every month
> --
>
> Key: AMQ-5645
> URL: https://issues.apache.org/jira/browse/AMQ-5645
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.9.0, 5.11.0
> Environment: Windows, Java 1.6
>Reporter: Toni Ramírez
>Assignee: Timothy Bish
> Fix For: 5.11.2, 5.12.0
>
>
> When we try to get a NextSecheduledTime for a cron string that should return
> next month's first day ("0 1 1 * *") we get current month's last day.
> For example:
> public static void main(String[] args){
>
> try{
>
> Date miFecha = new
> Date(CronParser.getNextScheduledTime("0 1 1 * *",
> System.currentTimeMillis()));
>
> System.out.println(miFecha);
>
>
> }catch(Exception e){
>
> e.printStackTrace();
> }
>
>
> }
> This prints:
> Tue Mar 31 01:00:00 CEST 2015
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-4848) activemq:list - Should include the transport connectors and their urls
[ https://issues.apache.org/jira/browse/AMQ-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705736#comment-15705736 ] ASF GitHub Bot commented on AMQ-4848: - Github user asfgit closed the pull request at: https://github.com/apache/activemq/pull/59 > activemq:list - Should include the transport connectors and their urls > -- > > Key: AMQ-4848 > URL: https://issues.apache.org/jira/browse/AMQ-4848 > Project: ActiveMQ > Issue Type: Improvement > Components: OSGi/Karaf >Reporter: Claus Ibsen >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 5.15.0 > > > When using the karaf commands you can get a bit of information about the > broker. > But we need to output the transport connectors in use as well, so you can see > the types and url's, eg tcp://localhost:61616, and ampq:xxx and so forth. > We could add that to the list command that shows the broker names. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-4848) activemq:list - Should include the transport connectors and their urls
[ https://issues.apache.org/jira/browse/AMQ-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705717#comment-15705717 ] Claus Ibsen commented on AMQ-4848: -- Its IMHO better to create a new command to list the transport connectors, as the existing is for listing only brokers. Contributions is welcome for a new command: activemq:transports-list > activemq:list - Should include the transport connectors and their urls > -- > > Key: AMQ-4848 > URL: https://issues.apache.org/jira/browse/AMQ-4848 > Project: ActiveMQ > Issue Type: Improvement > Components: OSGi/Karaf >Reporter: Claus Ibsen >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 5.15.0 > > > When using the karaf commands you can get a bit of information about the > broker. > But we need to output the transport connectors in use as well, so you can see > the types and url's, eg tcp://localhost:61616, and ampq:xxx and so forth. > We could add that to the list command that shows the broker names. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon reassigned AMQ-6521:
---
Assignee: Christopher L. Shannon
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.15.0
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705588#comment-15705588
]
Timothy Bish commented on AMQ-6521:
---
It might still be possible to let this work with jetty 9.3 on 5.14.x but we'll
need test out a few changes to see for sure.
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Priority: Minor
> Fix For: 5.15.0
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-866) make replication and quorum voting configurable and more resilient
[ https://issues.apache.org/jira/browse/ARTEMIS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705482#comment-15705482 ] ASF subversion and git services commented on ARTEMIS-866: - Commit 2d81f0a8d0df8ccca37416fabaa2a3f015e18eda in activemq-artemis's branch refs/heads/master from [~andytaylor] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=2d81f0a ] ARTEMIS-866 - quorum fixes remove reconnect attempt as it serves no purposes as replication has stopped anyway. Ensure if vote fails thatthe latch is counted down to avoid delay. If we can't detect live has failed signal failure in replicating. https://issues.apache.org/jira/browse/ARTEMIS-866 > make replication and quorum voting configurable and more resilient > -- > > Key: ARTEMIS-866 > URL: https://issues.apache.org/jira/browse/ARTEMIS-866 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 1.5.0 >Reporter: Andy Taylor >Assignee: Andy Taylor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-866) make replication and quorum voting configurable and more resilient
[ https://issues.apache.org/jira/browse/ARTEMIS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705484#comment-15705484 ] ASF GitHub Bot commented on ARTEMIS-866: Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/901 > make replication and quorum voting configurable and more resilient > -- > > Key: ARTEMIS-866 > URL: https://issues.apache.org/jira/browse/ARTEMIS-866 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 1.5.0 >Reporter: Andy Taylor >Assignee: Andy Taylor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-866) make replication and quorum voting configurable and more resilient
[ https://issues.apache.org/jira/browse/ARTEMIS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705483#comment-15705483 ] ASF subversion and git services commented on ARTEMIS-866: - Commit 2d81f0a8d0df8ccca37416fabaa2a3f015e18eda in activemq-artemis's branch refs/heads/master from [~andytaylor] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=2d81f0a ] ARTEMIS-866 - quorum fixes remove reconnect attempt as it serves no purposes as replication has stopped anyway. Ensure if vote fails thatthe latch is counted down to avoid delay. If we can't detect live has failed signal failure in replicating. https://issues.apache.org/jira/browse/ARTEMIS-866 > make replication and quorum voting configurable and more resilient > -- > > Key: ARTEMIS-866 > URL: https://issues.apache.org/jira/browse/ARTEMIS-866 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 1.5.0 >Reporter: Andy Taylor >Assignee: Andy Taylor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705448#comment-15705448
]
Carsten Hammer commented on AMQ-6521:
-
Thanks, that would be great!
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Priority: Minor
> Fix For: 5.15.0
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-6521:
Fix Version/s: 5.15.0
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Priority: Minor
> Fix For: 5.15.0
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6521) compatibility issue with jetty 9.3.11 in org.apache.activemq.transport.http.HttpTransportServer
[
https://issues.apache.org/jira/browse/AMQ-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705440#comment-15705440
]
Christopher L. Shannon commented on AMQ-6521:
-
We can target support for Jetty 9.3.x (and maybe Jetty 9.2.x backwards
compatibility) with the 5.15.0 release as that is the first release that will
require Java 8. The 5.14.x release branch still supports Java 7 so we can't
upgrade to Jetty 9.3.x in a 5.14.x release.
> compatibility issue with jetty 9.3.11 in
> org.apache.activemq.transport.http.HttpTransportServer
> ---
>
> Key: AMQ-6521
> URL: https://issues.apache.org/jira/browse/AMQ-6521
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: Carsten Hammer
>Priority: Minor
> Fix For: 5.15.0
>
>
> There is a instantiation of a class that does not exists, see
> org.apache.activemq.transport.http.HttpTransportServer.java:
> private void addGzipHandler(ServletContextHandler contextHandler) throws
> Exception {
> Handler handler = new GzipHandler();
> contextHandler.setHandler(handler);
> }
> org.eclipse.jetty.servlets.gzip.GzipHandler does not exist. Instead there is
> a class org.eclipse.jetty.server.handler.gzip.GzipHandler.java
> in
> https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.3.13.v20161014
> Because of this activemq is not compatible with jetty versions since 9.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-6522) KahaDB - checkForCorruptJournalFiles has hard coded 32k batch size limit in error
[ https://issues.apache.org/jira/browse/AMQ-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-6522. - Resolution: Fixed > KahaDB - checkForCorruptJournalFiles has hard coded 32k batch size limit in > error > -- > > Key: AMQ-6522 > URL: https://issues.apache.org/jira/browse/AMQ-6522 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB, Message Store >Affects Versions: 5.14.0 >Reporter: Gary Tully >Assignee: Gary Tully > Fix For: 5.15.0 > > > Using setCheckForCorruptJournalFiles=true, there is a sanity check of the > journal at startup - skipping through each of the journal files validating > batch record checksums and magic in an effort to detect corruption early and > drop the relevant messages or error out. > There is an error in the check logic that assumes a batch record must be < > 32k which is not the case if a message is > 32k > Tidy up this check and add some more detail to the error messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-6522) KahaDB - checkForCorruptJournalFiles has hard coded 32k batch size limit in error
[
https://issues.apache.org/jira/browse/AMQ-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705032#comment-15705032
]
Gary Tully edited comment on AMQ-6522 at 11/29/16 11:35 AM:
symptom with a message > 32k in size{code}
14:23:16,374 | ERROR | AMQ-1-thread-1 | ActiveMQServiceFactory | Exception on
start: java.io.IOException: Detected missing/corrupt journal files referenced
by:[xxx] 1 messages affected.
java.io.IOException: Detected missing/corrupt journal files referenced by:[xxx]
1 messages affected.
{code}
was (Author: gtully):
symptom with a message > 32k in size{code}
14:23:16,374 | ERROR | AMQ-1-thread-1 | ActiveMQServiceFactory | Exception on
start: java.io.IOException: Detected missing/corrupt journal files referenced
by:[xxx] 1 messages affected.
java.io.IOException: Detected missing/corrupt journal files referenced
by:[0:TEST] 1 messages affected.
{code}
> KahaDB - checkForCorruptJournalFiles has hard coded 32k batch size limit in
> error
> --
>
> Key: AMQ-6522
> URL: https://issues.apache.org/jira/browse/AMQ-6522
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, Message Store
>Affects Versions: 5.14.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> Using setCheckForCorruptJournalFiles=true, there is a sanity check of the
> journal at startup - skipping through each of the journal files validating
> batch record checksums and magic in an effort to detect corruption early and
> drop the relevant messages or error out.
> There is an error in the check logic that assumes a batch record must be <
> 32k which is not the case if a message is > 32k
> Tidy up this check and add some more detail to the error messages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6522) KahaDB - checkForCorruptJournalFiles has hard coded 32k batch size limit in error
[
https://issues.apache.org/jira/browse/AMQ-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705032#comment-15705032
]
Gary Tully commented on AMQ-6522:
-
symptom with a message > 32k in size{code}
14:23:16,374 | ERROR | AMQ-1-thread-1 | ActiveMQServiceFactory | Exception on
start: java.io.IOException: Detected missing/corrupt journal files referenced
by:[xxx] 1 messages affected.
java.io.IOException: Detected missing/corrupt journal files referenced
by:[0:TEST] 1 messages affected.
{code}
> KahaDB - checkForCorruptJournalFiles has hard coded 32k batch size limit in
> error
> --
>
> Key: AMQ-6522
> URL: https://issues.apache.org/jira/browse/AMQ-6522
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, Message Store
>Affects Versions: 5.14.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> Using setCheckForCorruptJournalFiles=true, there is a sanity check of the
> journal at startup - skipping through each of the journal files validating
> batch record checksums and magic in an effort to detect corruption early and
> drop the relevant messages or error out.
> There is an error in the check logic that assumes a batch record must be <
> 32k which is not the case if a message is > 32k
> Tidy up this check and add some more detail to the error messages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6522) KahaDB - checkForCorruptJournalFiles has hard coded 32k batch size limit in error
[ https://issues.apache.org/jira/browse/AMQ-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705029#comment-15705029 ] ASF subversion and git services commented on AMQ-6522: -- Commit dad629e889b2116a778fd4f77680a1b2944b400f in activemq's branch refs/heads/master from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=dad629e ] [AMQ-6522] - remove hardcoded 32k batch limit from recovery check of the journal, fix and test > KahaDB - checkForCorruptJournalFiles has hard coded 32k batch size limit in > error > -- > > Key: AMQ-6522 > URL: https://issues.apache.org/jira/browse/AMQ-6522 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB, Message Store >Affects Versions: 5.14.0 >Reporter: Gary Tully >Assignee: Gary Tully > Fix For: 5.15.0 > > > Using setCheckForCorruptJournalFiles=true, there is a sanity check of the > journal at startup - skipping through each of the journal files validating > batch record checksums and magic in an effort to detect corruption early and > drop the relevant messages or error out. > There is an error in the check logic that assumes a batch record must be < > 32k which is not the case if a message is > 32k > Tidy up this check and add some more detail to the error messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6522) KahaDB - checkForCorruptJournalFiles has hard coded 32k batch size limit in error
Gary Tully created AMQ-6522: --- Summary: KahaDB - checkForCorruptJournalFiles has hard coded 32k batch size limit in error Key: AMQ-6522 URL: https://issues.apache.org/jira/browse/AMQ-6522 Project: ActiveMQ Issue Type: Bug Components: KahaDB, Message Store Affects Versions: 5.14.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 5.15.0 Using setCheckForCorruptJournalFiles=true, there is a sanity check of the journal at startup - skipping through each of the journal files validating batch record checksums and magic in an effort to detect corruption early and drop the relevant messages or error out. There is an error in the check logic that assumes a batch record must be < 32k which is not the case if a message is > 32k Tidy up this check and add some more detail to the error messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
