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 (Created) (JIRA)" <ji...@apache.org> on 2011/12/14 21:23:30 UTC
[jira] [Created] (QPID-3685)
org.apache.qpid.transport.Session#timeout
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: 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
[jira] [Closed] (QPID-3685)
org.apache.qpid.transport.Session#timeout
Posted by "Joel Caplin (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joel Caplin closed QPID-3685.
-----------------------------
> 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
[jira] [Updated] (QPID-3685)
org.apache.qpid.transport.Session#timeout
Posted by "Joel Caplin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joel Caplin updated QPID-3685:
------------------------------
Attachment: stacktrace.txt
stacktrace
> 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: 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
[jira] [Resolved] (QPID-3685)
org.apache.qpid.transport.Session#timeout
Posted by "Joel Caplin (Resolved) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (QPID-3685)
org.apache.qpid.transport.Session#timeout
Posted by "Joel Caplin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joel Caplin updated QPID-3685:
------------------------------
Attachment: patch
Very simple patch to apply to Session.java that allows public access to set the timeout. Could also include a getter etc...
> 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
[jira] [Commented] (QPID-3685)
org.apache.qpid.transport.Session#timeout
Posted by "Joel Caplin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169680#comment-13169680 ]
Joel Caplin commented on QPID-3685:
-----------------------------------
Note that if the client attempts to connect to the donor broker, the same problem manifests itself.
> 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