[jira] Created: (AMQ-1120) Race Condition can result in hang on remoteBrokerNameKnownLatch
Race Condition can result in hang on remoteBrokerNameKnownLatch --- Key: AMQ-1120 URL: https://issues.apache.org/activemq/browse/AMQ-1120 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 4.0.2, 4.0.1, 4.0 Environment: Windows XP, demand forwarding, failover == true Reporter: Chris Hofstaedter My environment is comprised of Windows XP, AMQ v4.0.2, demand forwarding, failover = true, client and broker are all within the same VM. Typically, my client and broker would not be within the same VM, but this issue was encountered while executing my junit tests - not in a typical deployment environment. Basically, DemandForwardingBridgeSupport.startLocalBridge() hangs on remoteBrokerNameKnownLatch.await(); It looks like the broker name becomes known prior to the call to await. I think the response is coming in after the triggerLocalStartBridge thread is spawned and the synchronized block in DemandForwardingBridgeSupport.startRemoteBridge() is exited but before the await call in triggerLocalStartBridge. Like I said, I've only run into this when running demand forwarding with client and broker in the same VM along with a high volume of messages sent immediately after the connection is established, which for me, is an artifact of junit testing. I have a relatively small number of clients that should connect fairly infrequently, so I just put a bandaid of a 100ms wait into TcpTransportServer.run right before getAcceptListener().onAccept() which allows my tests to complete successfully and has no appreciable impact on the performance I care about but it's obviously not a valid fix for the race condition. -- 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-1119) Deadlock in MutexTransport on shutdown with high volume of messages
Deadlock in MutexTransport on shutdown with high volume of messages
---
Key: AMQ-1119
URL: https://issues.apache.org/activemq/browse/AMQ-1119
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 4.0.2, 4.0.1, 4.0
Environment: Windows XP, demand forwarding, failover == true
Reporter: Chris Hofstaedter
I ran into a deadlock in the MutextTransport.oneway(Command command) function
when processing very high message volume (100% cpu utilization) at the time of
a shutdown. I'm running 4.0.2 on WinXP and within a demand forwarding
environment with failover = true.
I did trap this deadlock in the debugger and it looks like two commands are
crossing paths in opposite directions through the MutexTransport. One of the
commands is a MessageDispatch and the other is a ShutdownInfo. Now, when the
ShutdownInfo gets through the MutexTransport first, it tries to shutdown the
background thread of the TcpTransport. However, this thread is currently
servicing the MessageDispatch and is blocked on the MutexTransport. Deadlock.
So, my patch was simply to avoid entering the synchronized(writeMutex) block in
the oneway(Command command) function of MutexTransport if
command.isShutdownInfo() returns true:
if (command.isShutdownInfo())
next.oneway(command);
else
synchronized(writeMutex) {
next.oneway(command);
}
--
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-1118) dangling thread after shutdown broker with a managed transport
dangling thread after shutdown broker with a managed transport -- Key: AMQ-1118 URL: https://issues.apache.org/activemq/browse/AMQ-1118 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2, 4.0.1, 4.0 Environment: Windows XP, demand forwarding, failover == true Reporter: Chris Hofstaedter I ran into a problem in which I end up with an orphaned thread every time I bounce a broker with a managed transport. I realize this may not be a big deal in many scenarios, but we may end up bouncing our broker everytime a user changes some configuration settings in our application and we need the app to run indefinitely. So orphaned threads are a concern to me. I traced it down to BrokerService.startTransportConnector(). In this function, if isUseJmx() returns true, the connector is decorated/replaced through a call to connector.asManagedConnector(). Turns out the broker never stores the reference to the newly created managed connector anywhere. I added transportConnectors.add(connector) to add the new managed connector to the broker's container of connectors and it seems to work in that all threads are shutdown cleanly even when the transport connector is managed. -- 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-1117) It would be helpful if some of the log messages that are logged at higher severity levels than they are presently
It would be helpful if some of the log messages that are logged at higher severity levels than they are presently - Key: AMQ-1117 URL: https://issues.apache.org/activemq/browse/AMQ-1117 Project: ActiveMQ Issue Type: Wish Affects Versions: 4.1.0, 4.0.2, 4.0.1, 4.0 Reporter: Chris Hofstaedter It would be helpful if the messages pertaining to transport interrupted and transport resumed were logged at INFO rather than DEBUG. It would be helpful if the messages pertaining to security errors were logged at ERROR rather than INFO. All of these log messages are in DemandForwardingBridgeSupport in the following functions: public void start() // for Transport Interrupted public void start() // for Transport Resumed protected void serviceRemoteException() // for Security errors -- 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-1116) deadlock when shutting down client that is configured with failover=true and is presently disconnected from broker
deadlock when shutting down client that is configured with failover=true and is
presently disconnected from broker
--
Key: AMQ-1116
URL: https://issues.apache.org/activemq/browse/AMQ-1116
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 4.0.2
Reporter: Chris Hofstaedter
Sounds like a great idea to me :) Please go ahead and submit a jira with the
patch and we'll get it integrated ASAP
On 1/4/07, Chris Hofstaedter <[EMAIL PROTECTED]> wrote:
> I ran into this issue as well on <= 4.0.2. I never tested it against
> 4.1.The FailoverTransport doesn't shutdown if it is disconnected at
> the time of the shutdown.
>
> I believe that the root cause is in the
> FailoverTransport.oneway(Command
> command) function which will hold onto the command and keep trying to
> reconnect until the message is sent or the transport is disposed.
>
> I applied a local patch that seems to solve the problem. Note that
> I've only tested the patch against 4.0.2.
>
> Specifically, I early return from the oneway function if the command
> is ShutdownInfo and the connectedTransport is null. This seems to
> solve the problem in that I get clean shutdowns on the client when
> failover is true and the client is presently disconnected.
>
> Does this seem like a reasonable patch? Should I create a JIRA with
> this info?
>
>
>
> -Original Message-
> From: James Strachan [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 12, 2006 4:46 AM
> To: activemq-users@geronimo.apache.org
> Subject: Re: failover mode and client shutdown
>
> There could be a bug relating to closes with the failover transport
> possibly, but the ActiveMQConnection does wait up to the closeTimeout
> for a close to succeed before shutting down - so you could try reduce
> the timeout.
>
> http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/a
> pa
> che/activemq/ActiveMQConnection.html#setCloseTimeout(int)
>
>
> On 12/12/06, Keith Irwin <[EMAIL PROTECTED]> wrote:
> > Folks--
> >
> > When we have clients running and we take down AMQ (<= 4.1.0), then
> > attempt to shutdown the clients with Control-C (rather than kill the
> > JVM with a -9), the clients won't shut down. It's as if a "close"
> > on the failover connection never reaches the amq client classes.
> >
> > I note that in the 4.1.0 release notes, this issue is referenced,
> > and the advice is to set the maxReconnectAttempts (or similar)
> > property to something non-zero.
> >
> > The problem is that we don't want there to be a max number of
> > attempts. Unless we specifically want to take down the client (say,
> > for an apt-get package upgrade), we want it to keep on trying
> > forever.
> >
> > SO, my question: Is there an architectural reason for not being able
> > to close a failover connection if AMQ is down?
> >
> > If it isn't impossible due to tradeoffs elsewhere in the code base,
> > we might be willing to submit a patch to fix the issue.
> >
> > Our only other recourse is to attempt to close the connections in
> > separate threads, then timeout those threads after a while and fall
> > out the end of the java process.
> >
> > For instance:
> >
> > Thread th = new Thread(new Runnable() {
> > public void run() {
> > connection.close();
> > }
> >});
> >th.start();
> >
> >// give up after 2 seconds
> >Thread.currentThread().join(2000);
> >
> > I guess this is do-able, but it seems, you know, some how, well,
> wrong.
> >
> > So, is it worth investigating a patch to AMQ?
> >
> > Keith
> >
--
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] Commented: (AMQ-734) Network connections do not reconnect when using static: with failover=true
[ https://issues.apache.org/activemq/browse/AMQ-734?page=comments#action_37516 ] Chris Hofstaedter commented on AMQ-734: --- I've got what I think is a fix for AMQ-734. However, the fix is possibly heavy-handed in its implementation, so I'd like for someone to review it and provide comments regarding any potential unintended side effects. I've attached to the issue in JIRA a junit case that is able to reproduce the issue 100% of the time as well as the necessary updates to DiscoveryNetworkConnector and DemandForwardingBridgeSupport. Basically, the classes were stopping the local broker and bridge whenever any exception was encountered on the transport. However, some of the exceptions are "ok" and should not result in a stop. These include InvalidClientIDException, BrokerStoppedException, InvalidStateException, and SocketException. With the fix, for these specific exceptions, the broker/bridge are not stopped and fireServiceFailed is never called. For all other exceptions, they still are called. In addition, the TransportListener.transportResumed implementation in DemandForwardingBridgeSupport never started the local/remote broker and never called triggerRemoteStartBridge. With this fix, they now do. I've run the whole suite of tests and all of the tests that passed prior to my modifications continue to pass. In addition, the test case attached to the JIRA fails without the fixes and passes with the fixes 100% of the time. Comments? > Network connections do not reconnect when using static: with failover=true > -- > > Key: AMQ-734 > URL: https://issues.apache.org/activemq/browse/AMQ-734 > Project: ActiveMQ > Issue Type: Bug > Components: Connector >Affects Versions: 4.0 > Environment: winxp java1.5.6 >Reporter: tao > Assigned To: Hiram Chirino >Priority: Critical > Fix For: 4.2.0, 4.1.1 > > Attachments: Amq734Test.java, Amq734Test.java, > DemandForwardingBridgeSupport.java, DiscoveryNetworkConnector.java > > > If I pull out RJ45 port from net card ,waiting a time ,then put RJ45 port > net card .Network is resume.Other computer always throw errors and net > channel can't work. -- 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] Commented: (AMQ-1049) SimpleAuthenticationBroker and AbstractConnection allow messages from a Producer that fails logon
[
https://issues.apache.org/activemq/browse/AMQ-1049?page=comments#action_37481 ]
Chris Hofstaedter commented on AMQ-1049:
I just tried this with the 4.0.2 release and the problem does not exist there.
> SimpleAuthenticationBroker and AbstractConnection allow messages from a
> Producer that fails logon
> -
>
> Key: AMQ-1049
> URL: https://issues.apache.org/activemq/browse/AMQ-1049
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.1.0, 4.0.1
> Environment: The OS is Windows XP. The producer is running in one
> JVM loaded via JNI invokation with an embedded broker and a
> DemandForwardingBridge that
> is connecting to the remote broker via "tcp://127.0.0.1:61616". The consumer
> and the BrokerService are running on the same machine but in another JVM also
> loaded via JNI invokation but communicating with each other via
> "vm://localhost".
>Reporter: Chris Hofstaedter
>
> I was trying to set up a SimpleAuthenticationBroker programatically rather
> than through the xml. I've tried with 4.0.1 and 4.1. The symptom was that,
> although the broker is set as an intercepter and it detects a bad password
> and emits a SecurityException, the producer is still allowed to produce
> messages. I can see the producer get the bad login indication through the
> following log message:
> WARN org.apache.activemq.network.DemandForwardingBridge - Unexpected remote
> command: ConnectionError {commandId = 2, responseRequired = false,
> connectionId = null, exception = java.lang.SecurityException: User name or
> password is invalid.}
> But then, the next thing I know, my consumers, that have successfully logged
> in, start receiving messages from this very same producer.
> After some investigation, I've been able to get the behavior I want, but I
> had to modify AbstractConnection.java to do it. I dont know if my
> modifications are appropriate, so could someone take a look and let me know
> whether this is a desirable change or not?
> Specifically, I added an additional catch block after line 202 of
> AbstractConnection and before the catch(Throwable). The new code is:
> catch ( SecurityException e1)
>{
>ConnectionError ce = new ConnectionError();
>ce.setException(e1);
>dispatchSync(ce);
>try
> {
> this.stop();
> }
>catch (Exception e2)
> {
> serviceLog.error("Unable to stop the connection after the
> SecurityException: " + e2);
> }
> Notice the dispatchSync versus dispatchAsync - I did this to ensure that the
> client was informed off the security violation before the connection is
> stopped.
--
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
