[jira] Created: (AMQ-770) consumer.dispatchAsync defaults to false
consumer.dispatchAsync defaults to false Key: AMQ-770 URL: https://issues.apache.org/activemq/browse/AMQ-770 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0, 4.0.1 Reporter: Kevin Yaussy Priority: Minor Seems like there was a change between 4.0-RC3 and incubator-4.0(.1) with regards to the default value for the destination option consumer.dispatchAsync. According to the web documentation for destination options, as well as behavior in RC3, the default is true. However, it looks like incubator-4.0(.1) defaults to false. I have to explicitly give the consumer.dispatchAsync=true for a destination option, in order to get async dispatch in the Broker. Is this a code bug, or documentation bug? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-771) org.apache.activemq.broker.TransportConnection::stop should not attempt to send a message over the connection.
org.apache.activemq.broker.TransportConnection::stop should not attempt to send a message over the connection. -- Key: AMQ-771 URL: https://issues.apache.org/activemq/browse/AMQ-771 Project: ActiveMQ Type: Bug Components: Connector Versions: 4.0.1, 4.0 Reporter: Kevin Yaussy Especially when using failover, there can be a problem with respect to TransportConnection::stop attempting to send a shutdown message over the connection. If another thread is sending messages to the connection, and it gets stuck for some reason, such as a network freeze, the target machine panics, or the target process freezes for some reason, the TransportConnection::dispatch will eventually block, locking the MutextTransport object. When the InactivityMonitor wakes up and detects that the connection is dead, it will go through the process of stopping the connection. This goes back into TransportConnection, and calls stop, which attemtps to lock the MutexTransport so it can send the shutdown command. Now, both threads are stuck, potentially for a long time, as a box panic will not cleanly close the tcp connection. I'm not sure the rationale for wanting to send a shutdown command to the other side of the connection, since the target has to handle the connection going down hard anyway. Seems to me, if you are intending on closing the connection, just close it - don't try to be nice to the other side. Especially in this code path, there is something wrong with the other side anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ] Kevin Yaussy reopened AMQ-608: -- Hiram, Very sorry that I did not look at the 4.0.1 source until the last couple days. I'd like to submit patches this time (I don't have svn, but I will attach regular diff -u patches). For DemandForwardingBridgeSupport, there was just one change that was left out. For FailoverTransport, it looks like things got changed around in kind of the opposite direction I was looking for. For me, I really don't care about the message waiting for transport to reconnect that comes out once a second during a send. Seemed like that one was less meaningful than the message waiting + reconnectDelay + ms before attempting connection. That's the one I would prefer to be debug, whereas the other message would be trace. Then, additionally, I am including a logging patch for InactivityMonitor.java. I would like to be able to see when readCheck is going to throw InactivityIOException and also show the connection info. I also don't care about the other debug stuff. So, I changed the readCheck log message to be info and added the toString to the message. Alternatively, I have a second patch that does the same thing, but turns all current debug into trace, and just the readCheck message to debug. Either way is good for me. The issue here is that the Broker won't show this InactivityIOException, and I'd like to see it (just not all the other debug stuff). The client-side, I think, is OK since now the TransportListener interrupted / resumed works. But the broker is silent about this and I would like to see it. Thanks. Change logging level of some DemandForwardingBridge log messages. - Key: AMQ-608 URL: https://issues.apache.org/activemq/browse/AMQ-608 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.0.1, 4.1 Attachments: DemandForwardingBridge.java, DemandForwardingBridgeSupport.java, FailoverTransport.java, FailoverTransport.java In DemandForwardingBridge, I'd like to be able to see subscription messages (and unsubscription messages), but not bridging messages. Both classes of log messages are log.trace. Seems like the bridging messages should remain trace, as you would want to look at that when you are doing pretty detailed debugging. However, I'd like to see subscribe/unsubscribe messages all the time. If those could be either info or debug, that would allow me to turn those on separately. I realize that I can see what is currently subscribed via the JMX console. However, seeing the subscribe/unsubscribe messages will allow diagnostics over time - who subscribed when type of questions. Mainly, I'm referring to messages logged as trace in: DemandForwardingBridge.serviceRemoteConsumerAdvisory DemandForwardingBridge.removeDemandSubscription -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ] Kevin Yaussy updated AMQ-608: - Attachment: DemandForwardingBridgeSupport.patch FailoverTransport.patch InactivityMonitor.patch Hope this is the way to attach the patches... Kevin. Change logging level of some DemandForwardingBridge log messages. - Key: AMQ-608 URL: https://issues.apache.org/activemq/browse/AMQ-608 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.0.1, 4.1 Attachments: DemandForwardingBridge.java, DemandForwardingBridgeSupport.java, DemandForwardingBridgeSupport.patch, FailoverTransport.java, FailoverTransport.java, FailoverTransport.patch, InactivityMonitor.patch In DemandForwardingBridge, I'd like to be able to see subscription messages (and unsubscription messages), but not bridging messages. Both classes of log messages are log.trace. Seems like the bridging messages should remain trace, as you would want to look at that when you are doing pretty detailed debugging. However, I'd like to see subscribe/unsubscribe messages all the time. If those could be either info or debug, that would allow me to turn those on separately. I realize that I can see what is currently subscribed via the JMX console. However, seeing the subscribe/unsubscribe messages will allow diagnostics over time - who subscribed when type of questions. Mainly, I'm referring to messages logged as trace in: DemandForwardingBridge.serviceRemoteConsumerAdvisory DemandForwardingBridge.removeDemandSubscription -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ] Kevin Yaussy updated AMQ-608: - Attachment: InactivityMonitor.patch2 Change logging level of some DemandForwardingBridge log messages. - Key: AMQ-608 URL: https://issues.apache.org/activemq/browse/AMQ-608 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.0.1, 4.1 Attachments: DemandForwardingBridge.java, DemandForwardingBridgeSupport.java, DemandForwardingBridgeSupport.patch, FailoverTransport.java, FailoverTransport.java, FailoverTransport.patch, InactivityMonitor.patch, InactivityMonitor.patch2 In DemandForwardingBridge, I'd like to be able to see subscription messages (and unsubscription messages), but not bridging messages. Both classes of log messages are log.trace. Seems like the bridging messages should remain trace, as you would want to look at that when you are doing pretty detailed debugging. However, I'd like to see subscribe/unsubscribe messages all the time. If those could be either info or debug, that would allow me to turn those on separately. I realize that I can see what is currently subscribed via the JMX console. However, seeing the subscribe/unsubscribe messages will allow diagnostics over time - who subscribed when type of questions. Mainly, I'm referring to messages logged as trace in: DemandForwardingBridge.serviceRemoteConsumerAdvisory DemandForwardingBridge.removeDemandSubscription -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
