You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Joel Caplin (Resolved) (JIRA)" <ji...@apache.org> on 2011/12/14 22:35:30 UTC

[jira] [Resolved] (QPID-3685) org.apache.qpid.transport.Session#timeout

     [ https://issues.apache.org/jira/browse/QPID-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joel Caplin resolved QPID-3685.
-------------------------------

    Resolution: Won't Fix

Will raise a C++ Broker JIRA - the broker should not accept connections while playing catch up...
                
> org.apache.qpid.transport.Session#timeout
> -----------------------------------------
>
>                 Key: QPID-3685
>                 URL: https://issues.apache.org/jira/browse/QPID-3685
>             Project: Qpid
>          Issue Type: Improvement
>          Components: C++ Broker, Java Client, Java Clustering
>    Affects Versions: 0.12
>         Environment: CentOS 6 mixed arch
>            Reporter: Joel Caplin
>         Attachments: patch, stacktrace.txt
>
>
> Suppose I have three C++ brokers (q1, q2, q3) in a cman/corosync-managed cluster. I have a java client J1.
> t0 - all three brokers are up
> t1 - q1 falls over
> t2 - q1 is restarted; catch up begins
> t3 - J1 starts; it connects to q1 and attempts to create a session
> t3 + 60000 milliseconds - J1 raises SessionException (see attached stack trace)
> The "timeout" field in org.apache.qpid.transport.Session is hard-coded to 60000ms. This is not desirable if the above situation is encountered since I have a client that falls 60 seconds behind in publishing.
> It appears this code is the culprit for the above:
> {code}
>                 if (state != OPEN && state != CLOSED && state != CLOSING)
>                 {
>                     Thread current = Thread.currentThread();
>                     if (!current.equals(resumer))
>                     {
>                         Waiter w = new Waiter(commands, timeout);
>                         while (w.hasTime() && (state != OPEN && state != CLOSED))
>                         {
>                             w.await();
>                         }
>                     }
>                 }
> {code}
> I appreciate this is a very-specific use case but in busy clusters where we do rolling upgrade, it's not actually an edge case but something that is happening frequently.
> Would it be possible to provision a "sessionCreateTimeout" or something similar in the URL? Or perhaps just a "sessionTimeout" value that can be used to setTimeout() in the class?
> Thanks
> JC

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org