Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Long timeouts to real sites with no MQTT

Hi Steve,

interestingly, my timings were from Ubuntu as well - a pretty vanilla
recent install of 12.04.

/proc/sys/net/ipv4/tcp_syn_retries has a value of 5.

But I still timeout after just 6 seconds. Odd.

N


On 26 February 2013 14:01, Steven Luke <stevejluke@xxxxxxxxx> wrote:
> Hi all, thanks for the great info.  Nick and Roger, I trued the timing
> command you posted, and like Dave I am on Ubuntu for development and get the
> same values as Roger.  If this were just a desktop app, a minute wait
> wouldn't be something I was too concerned about, but the target is Android
> as well, and on the mobile a minute is a long time (and sometimes it lasts
> longer on the android.  I will have to see if I can get similar timings from
> the Android when on 3G).
>
> Regardless, Dave, I do think I will file a change request on bugzilla, but
> will investigate a bit before hand.  You actually gave me a workaround in
> your post as well.  What I plan on doing is pre-testing the connection with
> my own Socket using the connect() with a timeout parameter.  If it succeeds,
> then connect via Paho.  Initial tests indicate it will work.  So thanks for
> the great info.
>
> Steve
>
> p.s.  I modified the emails below so they didn't duplicate too much, hope
> noone minds I edited their content by removing quoted text.
>
>
> On Tue, Feb 26, 2013 at 6:14 AM, <paho-dev-request@xxxxxxxxxxx> wrote:
>>
>> Date: Tue, 26 Feb 2013 09:47:44 +0000
>>
>> From: "Nicholas O'Leary" <nick.oleary@xxxxxxxxx>
>> To: General development discussions for paho project
>>         <paho-dev@xxxxxxxxxxx>
>> Subject: Re: [paho-dev] Long timeouts to real sites with no MQTT
>> Message-ID:
>>
>> <CAF=vhqeV0=u-HQW-PX1nPq8XFAydwF_Jp=vrYS7uCX5LGWRwaA@xxxxxxxxxxxxxx>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>>
>> Hi Steven,
>>
>> The connection timeout is there for when a socket is successfully
>> connected but the other end doesn't respond to the initial MQTT
>> connect packet exchange in a timely fashion.
>>
>> I've run your code a few times and it times out for my after roughly
>> 5-6 seconds:
>>
>> nol@noltop:/tmp/Mqttv3ClientOut/ship$ java -classpath
>> org.eclipse.paho.client.mqttv3.jar:. SuperSimple
>> (00:05.624)Exception: Unable to connect to server
>>
>> I get exactly the same results when I change the code to remove the
>> MqttClient altogether and just try to connect a raw socket (code
>> attached). Could you give that a go and see what you get?
>>
>> I also get the same result when I simply try telnet'ing to that
>> server/port:
>>
>> nol@noltop:~$ time telnet some.company.net 1883
>> Trying 82.98.86.161...
>> telnet: Unable to connect to remote host: Connection refused
>>
>> real 0m6.121s
>> user 0m0.000s
>> sys 0m0.000s
>>
>>
>>
>> What operating system are you running this on? I suspect there is an
>> underlying socket level timeout coming into play here.
>>
>> Cheers,
>> Nick
>>
>> On 26 February 2013 03:29, Steven Luke <stevejluke@xxxxxxxxx> wrote:
>> > When I make a connection to a valid looking Host Address, but which does
>> > not
>> > have an MQTT server running I get a seriously long timeout (I think it
>> > may
>> > actually never end in some cases).  I tried setting the Connection
>> > Timeout
>> > to 20, or 5, or anything, but it doesn't work.  Anything I can try to
>> > make
>> > the client realize the connection is no-good earlier?  Alternatively is
>> > there something I can manually do in another thread to make the
>> > connection
>> > stop trying?
>> >
>> > This is a big issue for me, because the setting will be
>> > user-configurable
>> > and if it takes this long to fail it means a negative and very visible
>> > user
>> > experience.  I would like it to fail in 30 seconds or less so I can
>> > prompt
>> > for them to modify the address without making them wait for minutes to
>> > set
>> > up.
>> >
>> > Thanks,
>> > Steve
>> >
>> > Here is sample code which shows the problem.  In plain desktop Java it
>> > takes
>> > a consistent 1 minute, 3 seconds to fail.  I use the same code on
>> > android,
>> > and on WiFi it takes about the same time (a little over a minute), but
>> > on
>> > 3G/4G it takes 2+ minutes, and I timed one (google.com) at >10 minutes
>> > before killing it.
>> >
>> > public class SuperSimple
>> > {
>> >     public static final String timeDiffFormat = "%1$tM:%1$tS.%1$tL";
>> >     private static MqttClient client;
>> >
>> >     public static void main(String... args)
>> >     {
>> >         final long startTime = System.currentTimeMillis();
>> >         try
>> >         {
>> >             client = new MqttClient("tcp://some.company.net:1883",
>> > "this_should_fail_fast");
>> >
>> >             MqttConnectOptions mOptions = new MqttConnectOptions();
>> >             mOptions.setKeepAliveInterval(20);
>> >             mOptions.setConnectionTimeout(20);
>> >             client.connect(mOptions);
>> >
>> >         }
>> >         catch (MqttException mEx)
>> >         {
>> >             long errorTime = System.currentTimeMillis();
>> >             Date difference = new Date(errorTime - startTime);
>> >             String time = String.format(Locale.US, timeDiffFormat,
>> > difference);
>> >             String message = mEx.getMessage();
>> >             System.out.printf("(%s)Exception: %s%n", time, message);
>> >         }
>> >
>> >         try
>> >         {
>> >             client.disconnect();
>> >         }
>> >         catch (MqttException e)
>> >         {
>> >             //This always happens: already disconnected.
>> >         }
>> >     }
>> > }
>> >
>> >
>> > _______________________________________________
>> > paho-dev mailing list
>> > paho-dev@xxxxxxxxxxx
>> > http://dev.eclipse.org/mailman/listinfo/paho-dev
>> >
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: SocketTest.java
>> Type: application/octet-stream
>> Size: 724 bytes
>> Desc: not available
>> URL:
>> <http://dev.eclipse.org/mailman/private/paho-dev/attachments/20130226/9dca35b4/attachment.obj>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 26 Feb 2013 10:32:40 +0000
>> From: Roger Light <roger@xxxxxxxxxx>
>>
>> To: General development discussions for paho project
>>         <paho-dev@xxxxxxxxxxx>
>> Subject: Re: [paho-dev] Long timeouts to real sites with no MQTT
>> Message-ID:
>>
>> <CAH7zdychRm125fwf44TRqNBkXw-zQ71RAsr=RyQRaj6j3q7xPw@xxxxxxxxxxxxxx>
>> Content-Type: text/plain; charset=UTF-8
>>
>>
>> On Tue, Feb 26, 2013 at 9:47 AM, Nicholas O'Leary <nick.oleary@xxxxxxxxx>
>> wrote:
>>
>> > nol@noltop:~$ time telnet some.company.net 1883
>>
>> I got the below on Ubuntu Linux.
>>
>> telnet: Unable to connect to remote host: Connection timed out
>>
>> real    1m3.235s
>> user    0m0.000s
>> sys     0m0.008s
>>
>> This can be controlled on a computer wide basis with
>> /proc/sys/net/ipv4/tcp_syn_retries - setting to "2" gave me a timeout
>> of about 7 seconds. This does affect other applications of course.
>>
>> The suggestions I've just seen for C code is to set the socket
>> non-blocking before a connect(), then use select() or similar to wait
>> for the connection with a timeout. I'll be looking at that for my own
>> code!
>>
>> Cheers,
>>
>> Roger
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Tue, 26 Feb 2013 11:13:56 +0000
>> From: Dave Locke <locke@xxxxxxxxxx>
>>
>> To: General development discussions for paho project
>>         <paho-dev@xxxxxxxxxxx>
>> Cc: paho-dev-bounces@xxxxxxxxxxx
>>
>> Subject: Re: [paho-dev] Long timeouts to real sites with no MQTT
>> Message-ID:
>>
>> <OFDC93ADD0.50967E5B-ON80257B1E.003CF6D0-80257B1E.003DB7E3@xxxxxxxxxx>
>> Content-Type: text/plain; charset="us-ascii"
>>
>>
>> The Java client creates a socket and connects using the SocketFactory
>> createSocket(host, port)method.    It is possible to use the SocketFactory
>> to create a socket but not connect and then set a timeout on the
>> socket.connect() method that will cause the connect to timeout if it does
>> not succeed (or fail) before the timeout.   If this would be useful please
>> raise a request on the paho bugzilla
>>
>>
>> All the best
>> Dave
>>
>> ...
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://dev.eclipse.org/mailman/private/paho-dev/attachments/20130226/d878fce8/attachment.html>
>>
>> ------------------------------
>>
>>
>> _______________________________________________
>> paho-dev mailing list
>> paho-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/paho-dev
>>
>>
>> End of paho-dev Digest, Vol 14, Issue 7
>> ***************************************
>
>
>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/paho-dev
>


Back to the top