Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Request for consideration

That is true of course. I don't know that bit of code well enough to know if it is appropriate to change this snippet of code. 

Paul




On 29 October 2013 21:41, Marc L Cohen <mlcohen@xxxxxxxxxx> wrote:

It might be, but that still leaves the problem of checking on the client side to determine how long you should be waiting when you do get disconnected and want to reconnect. There are other reasons for disconnect.




Marc L. Cohen
MessageSight Test/Development
Internet:mlcohen@xxxxxxxxxx
also at:teddybbear@xxxxxxx
(512) 286-5744 (T/L 363-5744)
FAX (512) 973-4293


Inactive hide details for Paul Fremantle ---10/29/2013 04:37:42 PM---Wouldn't it be more effective to apply back pressure to thPaul Fremantle ---10/29/2013 04:37:42 PM---Wouldn't it be more effective to apply back pressure to the client rather than disconnect it? In oth

From: Paul Fremantle <paul.fremantle@xxxxxxxxxx>
To: General development discussions for paho project <paho-dev@xxxxxxxxxxx>,
Date: 10/29/2013 04:37 PM
Subject: Re: [paho-dev] Request for consideration
Sent by: paho-dev-bounces@xxxxxxxxxxx




Wouldn't it be more effective to apply back pressure to the client rather than disconnect it? In other words, just don't read the PUBLISH from TCP until the message queue is less full?

Paul


On 29 October 2013 21:29, Marc L Cohen <mlcohen@xxxxxxxxxx> wrote:
    We have someone doing some testing that is having a problem with the Java client. The situation is this, the server is designed to queue up to a set maximum of messages. If a publisher tries to publish a message while this maximum is filled, the server closes the connection. The testcase gets to this point, and when it receives an Exception from the publish it tries to reconnect to the server. Sometimes this reconnection fails with "Client is currently disconnecting (32102)".
    It does eventually clear up the connection and reallow a new connection, but this can take a while, up to the KeepAliveInterval. What is happening is that in CommsSender.stop:


    if
     (!Thread.currentThread().equals(sendThread)) {
    try
     {
    // first notify get routine to finish

    clientState
    .notifyQueueLock();
    // Wait for the thread to finish.

    sendThread
    .join();
    }

    catch
     (InterruptedException ex) {
    }
    }


    It is the sendThread.join() that is taking the time. Is there any reason you can't add a sendThread.interrupt(); before the join to interrupt the wait?


    Marc L. Cohen
    MessageSight Test/Development

    Internet:mlcohen@xxxxxxxxxx
    also
    at:teddybbear@xxxxxxx
    (512) 286-5744 (T/L 363-5744)
    FAX
    (512) 973-4293

    _______________________________________________
    paho-dev mailing list

    paho-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/paho-dev



--
Paul Fremantle
Part-time PhD student - School of Computing
email: paul.fremantle@xxxxxxxxxx, paul@xxxxxxxxxxxxx
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev




--
Paul Fremantle
Part-time PhD student - School of Computing
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729

GIF image


Back to the top