Losing events on REST API (atmosphere)

[renatoriolino]

Hi guys!

I have built myself a microcontrolled hardware to automate my home and I'm using openhab as a interface.

The server talks with all the controllers via RS-485 and since I don't program in Java, I've made a C program to talk via rs485 with the hardware and via REST API with OpenHab.

Everything is working perfectly with OH 1.3.1 but not with OH 1.4.

With 1.4, I'm losting a lot of events (ex: I change a switch item via HABDroid my C application doesn't receive the update).

For polling the items, I'm using HTTP Header "X-Atmosphere-Transport: streaming".

Every time I lost an event, OH outputs the following on LOG:

00:01:56.844 WARN o.a.cpr.DefaultBroadcaster[:500]- This message Entry{message=Garagem (Type=SwitchItem, State=OFF), type=ALL, future=org.atmosphere.cpr.BroadcasterFuture@33d1d377} will be lost

Let me know if you need for information.

Thanks

Renato

[belovictor]

Do you see a message like '16:17:05.292 DEBUG o.o.i.r.i.b.GeneralBroadcaster[:41] - broadcaster 'org.openhab.io.rest.internal.broadcaster.GeneralBroadcaster$1@5507f60' is empty' right before the one you specified in your log?

[renatoriolino]

No, I don't see it on logs. Here is a little more log:

00:01:56.844 WARN o.a.cpr.DefaultBroadcaster[:500]- This message Entry{message=Garagem (Type=SwitchItem, State=OFF), type=ALL, future=org.atmosphere.cpr.BroadcasterFuture@33d1d377} will be lost 00:10:01.386 WARN o.a.cpr.DefaultBroadcaster[:500]- This message Entry{message=Garagem (Type=SwitchItem, State=ON), type=ALL, future=org.atmosphere.cpr.BroadcasterFuture@48dc7834} will be lost 00:10:05.645 WARN o.a.cpr.DefaultBroadcaster[:500]- This message Entry{message=Garagem (Type=SwitchItem, State=OFF), type=ALL, future=org.atmosphere.cpr.BroadcasterFuture@3af3987a} will be lost 00:49:04.315 INFO o.o.a.x.internal.XMPPConnect[:199]- XMPP connection has been closed on error: Connection reset 00:49:07.005 INFO o.o.a.x.internal.XMPPConnect[:117]- Connection to XMPP as 'casa.riolino@gmail.com' has been established. 00:49:07.007 INFO o.o.a.x.internal.XMPPConnect[:205]- XMPP re-connection succeeded. 00:51:02.178 WARN o.o.b.xbmc.rpc.XbmcConnector[:107]- Websocket closed. 00:51:02.186 WARN c.n.h.c.p.n.NettyAsyncHttpProvider[:2415]- onError [id: 0x7c9d1d54, /192.168.25.22:32934 :> /192.168.25.24:9090] EXCEPTION: org.jboss.netty.handler.codec.frame.CorruptedFrameException: invalid UTF-8 bytes 01:00:00.009 INFO org.openhab.model.script.temp[:53]- Resetando temperatura 01:52:46.782 WARN o.o.u.i.i.ItemUIRegistryImpl[:434]- Cannot find page for id 'renato'. 01:55:59.057 WARN o.a.cpr.DefaultBroadcaster[:500]- This message Entry{message=CorredorPequeno (Type=SwitchItem, State=ON), type=ALL, future=org.atmosphere.cpr.BroadcasterFuture@1348471} will be lost 01:57:18.253 WARN o.a.cpr.DefaultBroadcaster[:500]- This message Entry{message=CorredorPequeno (Type=SwitchItem, State=OFF), type=ALL, future=org.atmosphere.cpr.BroadcasterFuture@70471c9a} will be lost 02:00:00.008 INFO org.openhab.model.script.temp[:53]- Resetando temperatura 02:15:12.833 WARN o.o.u.i.i.ItemUIRegistryImpl[:434]- Cannot find page for id 'renato'. 02:15:29.903 WARN o.a.cpr.DefaultBroadcaster[:500]- This message Entry{message=org.openhab.io.rest.internal.resources.beans.PageBean@6e3dae12, type=RESOURCE, future=org.atmosphere.cpr.BroadcasterFuture@3afaa77b} will be lost

The log's settings are at defaults. Do I have to change any settings to enable more debug info on logs?

Thanks.

[renatoriolino]

Hi again!

Looking at other issues, I found issue 673 to be almost the same:

https://github.com/openhab/openhab/issues/673

[oliver-M]

Hi, can you post a complete HTTP request from your C application?

[renatoriolino]

I use libcurl for the request. Here I setup the headers:

    i->headers = curl_slist_append(i->headers, "Content-Type: text/html");
    i->headers = curl_slist_append(i->headers, "X-Atmosphere-Transport: streaming");
    snprintf(strAux, 64, "X-Atmosphere-tracking-id: %d", getpid() + cnt++);
    i->headers = curl_slist_append(i->headers, strAux);
    curl_easy_setopt(i->handle, CURLOPT_HTTPHEADER, i->headers);

The URL is defined here:

    curl_easy_setopt(i->handle, CURLOPT_URL, i->link);

where i->link is:

http://192.168.25.26:8080/rest/items/Garagem

When the item gets updated, my handle function uses libxml to parse the status change (but this function is never called when the lost event happens):

XMLDocument doc;
doc.Parse(p);
XMLElement *item = doc.FirstChildElement("item");
if (item != NULL)
    // proccess here the status change

Please let me know if you need more information.

Thanks

[oliver-M]

Ok, seems that openHab doesn't know how to answer your request. The "accept" HTTP header is missing. Please add "Accept: application/xml" to receive messages in XML format or "Accept: application/json" if you want a message in JSON format.

[renatoriolino]

@oliver-M, thank you.

After adding the http header "Accept: application/xml" no events was lost anymore. I'm still having other issues with 1.4 but I'll post on another topic.

Thanks again!

[renatoriolino]

Unfortunately the lost events issue persist. I updated OH 1.4 to build 594 and I'm sending the header "Accept: application/xml", but I'm still losing events:

15:17:15.625 WARN o.a.cpr.DefaultBroadcaster[:500]- This message Entry{message=HomeCentral (Type=SwitchItem, State=ON), type=ALL, future=org.atmosphere.cpr. BroadcasterFuture@13b0c03} will be lost

Which debug should I enable to help hunt this bug?

Thanks

[peuter]

I just tried to investigate this problem. It seems to be a problem with the streaming transport, when I use long-polling I get proper updates of the items. Please verify by comparing the results of these two queries:

curl --header "X-Atmosphere-Transport: long-polling" --header "Accept: application/json" http://192.168.25.26:8080/rest/items/Garagem

curl --header "X-Atmosphere-Transport: streaming" --header "Accept: application/json" http://192.168.25.26:8080/rest/items/Garagem

From my point of view this has nothing to do with the DefaultBroadcasters losing events log entries. There is rather some mistake in generating the response in streaming transport mode.

[oliver-M]

I will try to reproduce your findings..

[peuter]

I upgraded the atmosphere libs to the current version 2.1.1 and the streaming transport seems to be working again. Maybe you could test this against your setup, you can find my clone here: https://github.com/peuter/openhab

There is one problem that needs to be resolved before I can create a pull request: During start I get the following exception for all rest-based addons (cometvisu and rest): ERROR o.a.cpr.AtmosphereFramework[:2306] - java.lang.AssertionError: Not a File: \org\atmosphere\annotation

As the required libraries are included I don´t know how to solve this and it seems to have no impact on the functionality.

[kaikreuzer]

ERROR o.a.cpr.AtmosphereFramework[:2306] - java.lang.AssertionError: Not a File: \org\atmosphere\annotation

As the required libraries are included I don´t know how to solve this and it seems to have no impact on the functionality.

This is strange as I thought that assertions are not checked at runtime - they are normally disabled by default, see http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html#enable-disable

Could you try to add the launch parameter "-da“ and see if the error disappears?

Regards, Kai

[peuter]

The -da parameter does not help. This is the complete stacktrace:

ERROR o.a.cpr.AtmosphereFramework[:2306] - java.lang.AssertionError: Not a File: \org\atmosphere\annotation at org.atmosphere.util.annotation.AnnotationDetector.detect(AnnotationDetector.java:352) at org.atmosphere.cpr.DefaultAnnotationProcessor.scanForAnnotation(DefaultAnnotationProcessor.java:147) at org.atmosphere.cpr.DefaultAnnotationProcessor.configure(DefaultAnnotationProcessor.java:133) at org.atmosphere.cpr.AtmosphereFramework.autoConfigureService(AtmosphereFramework.java:2268) at org.atmosphere.cpr.AtmosphereFramework.init(AtmosphereFramework.java:707) at org.atmosphere.cpr.AtmosphereFramework.init(AtmosphereFramework.java:614) at org.atmosphere.cpr.AtmosphereServlet.init(AtmosphereServlet.java:86) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.init(ServletRegistration.java:49) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.registerServlet(ProxyServlet.java:179) at org.eclipse.equinox.http.servlet.internal.HttpServiceImpl.registerServlet(HttpServiceImpl.java:66) at org.openhab.io.cv.CVApplication.activate(CVApplication.java:142)

And the source code in AnnotationDetector is (lines 330-353): try { jarFile = toFile(((JarURLConnection) url.openConnection()).getJarFileURL()); } catch (ClassCastException cce) { try { // Weblogic crap String u = url.toExternalForm(); if (u.startsWith("zip:")) { u = u.substring(4); if (!u.startsWith("file:")) { u = "file:" + u; } u = u.substring(0, u.indexOf("!")); } jarFile = toFile(new URL(u)); } catch (Exception ex) { throw new AssertionError("Not a File: " + url.toExternalForm()); } } if (jarFile.isFile()) { files.add(jarFile); if (DEBUG) print("Add jar file: '%s'", jarFile); } else { throw new AssertionError("Not a File: " + jarFile); }

Regards, Tobias

Am 29.03.2014 18:27, schrieb kaikreuzer:

ERROR o.a.cpr.AtmosphereFramework[:2306] - java.lang.AssertionError: Not a File: \org\atmosphere\annotation

As the required libraries are included I don´t know how to solve this and it seems to have no impact on the functionality.

This is strange as I thought that assertions are not checked at runtime - they are normally disabled by default, see http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html#enable-disable

Could you try to add the launch parameter "-da“ and see if the error disappears?

Regards, Kai

— Reply to this email directly or view it on GitHub https://github.com/openhab/openhab/issues/765#issuecomment-39002412.

[kaikreuzer]

Probably best to ask for help in the Atmosphere support list?

Am 29.03.2014 um 18:48 schrieb peuter notifications@github.com:

The -da parameter does not help. This is the complete stacktrace:

ERROR o.a.cpr.AtmosphereFramework[:2306] - java.lang.AssertionError: Not a File: \org\atmosphere\annotation at org.atmosphere.util.annotation.AnnotationDetector.detect(AnnotationDetector.java:352) at org.atmosphere.cpr.DefaultAnnotationProcessor.scanForAnnotation(DefaultAnnotationProcessor.java:147) at org.atmosphere.cpr.DefaultAnnotationProcessor.configure(DefaultAnnotationProcessor.java:133) at org.atmosphere.cpr.AtmosphereFramework.autoConfigureService(AtmosphereFramework.java:2268) at org.atmosphere.cpr.AtmosphereFramework.init(AtmosphereFramework.java:707) at org.atmosphere.cpr.AtmosphereFramework.init(AtmosphereFramework.java:614) at org.atmosphere.cpr.AtmosphereServlet.init(AtmosphereServlet.java:86) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.init(ServletRegistration.java:49) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.registerServlet(ProxyServlet.java:179) at org.eclipse.equinox.http.servlet.internal.HttpServiceImpl.registerServlet(HttpServiceImpl.java:66) at org.openhab.io.cv.CVApplication.activate(CVApplication.java:142)

And the source code in AnnotationDetector is (lines 330-353): try { jarFile = toFile(((JarURLConnection) url.openConnection()).getJarFileURL()); } catch (ClassCastException cce) { try { // Weblogic crap String u = url.toExternalForm(); if (u.startsWith("zip:")) { u = u.substring(4); if (!u.startsWith("file:")) { u = "file:" + u; } u = u.substring(0, u.indexOf("!")); } jarFile = toFile(new URL(u)); } catch (Exception ex) { throw new AssertionError("Not a File: " + url.toExternalForm()); } } if (jarFile.isFile()) { files.add(jarFile); if (DEBUG) print("Add jar file: '%s'", jarFile); } else { throw new AssertionError("Not a File: " + jarFile); }

Regards, Tobias

Am 29.03.2014 18:27, schrieb kaikreuzer:

ERROR o.a.cpr.AtmosphereFramework[:2306] - java.lang.AssertionError: Not a File: \org\atmosphere\annotation

As the required libraries are included I don´t know how to solve this and it seems to have no impact on the functionality.

This is strange as I thought that assertions are not checked at runtime - they are normally disabled by default, see http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html#enable-disable

Could you try to add the launch parameter "-da“ and see if the error disappears?

Regards, Kai

— Reply to this email directly or view it on GitHub https://github.com/openhab/openhab/issues/765#issuecomment-39002412.

— Reply to this email directly or view it on GitHub.

[peuter]

It seems if someone did that already: https://groups.google.com/forum/#!topic/atmosphere-framework/Yo4E_gXkZv4

And an issue is filed for this problem too: https://github.com/Atmosphere/atmosphere/issues/1539

Am 29.03.2014 18:54, schrieb kaikreuzer:

Probably best to ask for help in the Atmosphere support list?

Am 29.03.2014 um 18:48 schrieb peuter notifications@github.com:

The -da parameter does not help. This is the complete stacktrace:

ERROR o.a.cpr.AtmosphereFramework[:2306] - java.lang.AssertionError: Not a File: \org\atmosphere\annotation at

org.atmosphere.util.annotation.AnnotationDetector.detect(AnnotationDetector.java:352)

at

org.atmosphere.cpr.DefaultAnnotationProcessor.scanForAnnotation(DefaultAnnotationProcessor.java:147)

at

org.atmosphere.cpr.DefaultAnnotationProcessor.configure(DefaultAnnotationProcessor.java:133)

at

org.atmosphere.cpr.AtmosphereFramework.autoConfigureService(AtmosphereFramework.java:2268)

at

org.atmosphere.cpr.AtmosphereFramework.init(AtmosphereFramework.java:707) at

org.atmosphere.cpr.AtmosphereFramework.init(AtmosphereFramework.java:614) at org.atmosphere.cpr.AtmosphereServlet.init(AtmosphereServlet.java:86) at

org.eclipse.equinox.http.servlet.internal.ServletRegistration.init(ServletRegistration.java:49)

at

org.eclipse.equinox.http.servlet.internal.ProxyServlet.registerServlet(ProxyServlet.java:179)

at

org.eclipse.equinox.http.servlet.internal.HttpServiceImpl.registerServlet(HttpServiceImpl.java:66)

at org.openhab.io.cv.CVApplication.activate(CVApplication.java:142)

And the source code in AnnotationDetector is (lines 330-353): try { jarFile = toFile(((JarURLConnection) url.openConnection()).getJarFileURL()); } catch (ClassCastException cce) { try { // Weblogic crap String u = url.toExternalForm(); if (u.startsWith("zip:")) { u = u.substring(4); if (!u.startsWith("file:")) { u = "file:" + u; } u = u.substring(0, u.indexOf("!")); } jarFile = toFile(new URL(u)); } catch (Exception ex) { throw new AssertionError("Not a File: " + url.toExternalForm()); } } if (jarFile.isFile()) { files.add(jarFile); if (DEBUG) print("Add jar file: '%s'", jarFile); } else { throw new AssertionError("Not a File: " + jarFile); }

Regards, Tobias

Am 29.03.2014 18:27, schrieb kaikreuzer:

ERROR o.a.cpr.AtmosphereFramework[:2306] - java.lang.AssertionError: Not a File: \org\atmosphere\annotation

As the required libraries are included I don´t know how to solve this and it seems to have no impact on the functionality.

This is strange as I thought that assertions are not checked at runtime - they are normally disabled by default, see

http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html#enable-disable

Could you try to add the launch parameter "-da“ and see if the error disappears?

Regards, Kai

— Reply to this email directly or view it on GitHub

https://github.com/openhab/openhab/issues/765#issuecomment-39002412.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/openhab/openhab/issues/765#issuecomment-39003209.

[teichsta]

Hi @digitaldan, any news on your post (mentioned in #1126) in the atmosphere forum? Could you please refer to your thread there? Best, Thomas E.-E.

[digitaldan]

There was a little discussion, but nothing that seemed relevant to our issue. I'm hoping to find more time tomorrow to look at it.

[digitaldan]

https://groups.google.com/forum/#!topic/atmosphere-framework/TVF18UwYMD8

[peuter]

I think the problem is described on this page: https://github.com/Atmosphere/atmosphere/wiki/onDisconnect-tricks

"If you are using Jetty (all versions), onDisconnect will not be called when there is an unexpected network outage or when the browser hasn't sent the close message."

[digitaldan]

@peuter that's an excellent find! I'm also reading: https://github.com/Atmosphere/atmosphere/wiki/Recovering-AtmosphereResource-State-between-reconnection

I had assumed that atmosphere would take care of this automatically, but maybe not. I'm playing around with the code right now, I'll let you know what I find. Thanks for the link.

[digitaldan]

My latest theory.... Because atmosphere is not hearing about disconnects a reconnect creates a second resource with the same UUID. Now, this is not suppose to happen, Atmosphere should cancel the first request and honor the new one, but this is not the case. You can test this by running wget with the same UUID concurrently, the expected outcome would be for the second request to cause the first one to abort, instead, both are held by the server, yet only the first one continues to behave.
I will continue to investigate, I'm going to post back over to the atmosphere list as well.

[digitaldan]

Good news, i think i have a fix. I still would like to get feedback from the atmosphere group about the correct way to handle this problem. Its a simple change, before we suspend a request, we first check if there are any outstanding one for the same UUID, if so close them. So far so good with my testing. You can view the change here: https://github.com/digitaldan/openhab/commit/ce7232ef5ee53b2d97f207f18ee1edef0e270d18

Again, I know we probably should not need to do this, but if all else fails....

[digitaldan]

I think I have a fix that will make this work for everyone, it handles disconnects, timeouts, server restarts ect.., once a client has an atmosphere id, they can continue to use it for all future requests and the server will respond appropriately. So for the android client, after you have your atmosphere id, you can continue to use this for all future requests for a sitemap page, even if you go offline for hours and come back, it should work the right way. The atmosphere framework is very dependent on the server knowing when a disconnect happens, however Jetty has an issue where it won't hear about client side disconnects. I don't think atmosphere handles the non happy path as transparently as I had assumed, so I think this is our best solution for the time being.

[peuter]

Hi Dan thanks for your solution, I tried to check it and it seems to work, with one exception. But because I have some changes in my local repository, maybe one of these changes could cause the error, so please try to reproduce my findings.

It seems that, when the existing connection gets closed the cached messages get lost too. When you do the following steps

1. curl -v -k "http://localhost:8080/rest/sitemaps/demo/0301"
2. curl -v -k --header "X-Atmosphere-Transport: long-polling" --header "X-Atmosphere-tracking-id: a59106ca-e556-4bfb-87bd-f7d53a48da70" --header "X-Atmosphere-Framework: 1.0" --header "Accept: application/json" "http://localhost:8080/rest/sitemaps/demo/0301"
3. abort the request from step 2
4. Change the Switch in the gui
5. repeat step 2

the request in step 5 should not be suspended but receive the cached item state change. If you don´t abort the request in step 2 the caching mechanism works fine.

I hope you can understand what I´m talking about, it´s kind of hard to describe.

[digitaldan]

Nope your right, let me look at that.

On Tue, Jun 24, 2014 at 11:47 AM, peuter notifications@github.com wrote:

Hi Dan thanks for your solution, I tried to check it and it seems to work, with one exception. But because I have some changes in my local repository, maybe one of these changes could cause the error, so please try to reproduce my findings.

It seems that, when the existing connection gets closed the cached messages get lost too. When you do the following steps

1. curl -v -k "http://localhost:8080/rest/sitemaps/demo/0301"
2. curl -v -k --header "X-Atmosphere-Transport: long-polling" --header "X-Atmosphere-tracking-id: a59106ca-e556-4bfb-87bd-f7d53a48da70" --header "X-Atmosphere-Framework: 1.0" --header "Accept: application/json" " http://localhost:8080/rest/sitemaps/demo/0301"
3. abort the request from step 2
4. Change the Switch in the gui
5. repeat step 2

the request in step 5 should not be suspended but receive the cached item state change. If you don´t abort the request in step 2 the caching mechanism works fine.

I hope you can understand what I´m talking about, it´s kind of hard to describe.

— Reply to this email directly or view it on GitHub https://github.com/openhab/openhab/issues/765#issuecomment-47004722.

[digitaldan]

Just an update. The problem here it that Jetty (and sometimes Java in general) does not detect a far end TCP disconnect and does not know if a connection is lost or not. This means during a disconnect if an event is sent to the client, atmosphere will attempt to send it to our dead connection and get us out of sync. I'm trying to figure a way out to detect the state and react accordingly. Writing to a closed connection should be causing a socket exception in Jetty, but its swallowing it somewhere, catching this would be ideal.

[belovictor]

The tricky point here is that it used to work fine. So why suddenly Jetty is not recognising connection drop off? Another point - when connection is closed by HTTP response timeout (and that's the main case we are talking about here), it is gracefully closed either on server or on the client side. Which means it is gracefully closed on TCP level so the other end receives close notification, thus java socket and jetty which is afaik sitting on top of it should get notification. 100%.

[belovictor]

Let's do an experiment. Decrease HTTP timeout on Jetty side to let say 10 seconds. This will be less then any of our UI apps. In this case Jetty will be the guy closing http connection so he should know about it! :-)

[digitaldan]

Hey Victor! Graceful timeouts should be working fine right now, its just the case where we have an unexpected disconnect, like a poor wifi or cell connection. If jetty closes the connection before the client we are good.

I was hoping to make the clients as dumb as possible, so they would not have to know much about state, but this is looking difficult. If the clients could react to disconnect (anything other then a 200 response) and connect again with a fresh atmosphere id then I think we could close this issue. Since clients should not be getting this often, I'm hoping this could be an acceptable solution.

Im trying to figure out how it could have worked before, according to https://github.com/Atmosphere/atmosphere/wiki/onDisconnect-tricks Jetty has not been able to detect disconnects, indeed when I kill a client, jetty and atmosphere don't make a peep! Could there be a JVM option to tune or something?

[digitaldan]

Jeanfrancois on the Atmosphere list is saying that with NIO we should be hearing about disconnects so I'm following up with him over there. If we can get that working, then I think we can go back to using what we had and move on with our lives ;-)

As you pointed out @belovictor , it used to work, so I wonder if something has caused Jetty to go from NIO to the older java.net.socket implementation? This was the default behavior in Jetty prior to version 7.

[belovictor]

digitaldan, any news on that?

[digitaldan]

Last I left it I was trying to upgrade the jetty libs to the newest version, I'm on the road right now, flying back home tomorrow, so I'll have some more time to play. The Jetty libs are configured outside the binding, if someone could point me to the right file to do this in that would be great (still new to osgi). Atmosphere should be doing what we want, the lead developer is recommending we try upgrading our versions of jetty, so I want to do that before getting back to him.

[kaikreuzer]

Just as a warning: I just upgraded to Jetty 9.2.1 for the openHAB 2 stream - this brings new dependencies to javax.servlet, this again to a newer equinox and this draws many other dependencies in that needs to be upgraded. So an upgrade of Jetty to the latest version is definitely something way beyond a patch release 1.5.1. Probably better to stay on some Jetty 8 version or even downgrade (as it all used to work once...)

[digitaldan]

I was only going to update to the latest 8 version (Stable 8.1.15.v20140411), I don't think its going to make a difference, but I wanted to exhaust our options before going back to the atmosphere mailing list.

[kaikreuzer]

Ok, that sounds fair :-)

[teichsta]

thanks for this update, Dan!

[digitaldan]

Quick update, for sanity sake I checked out their jersey-pubsub example and I'm seeing the exact same behavior when a client abruptly disconnects, so I don't think it us. I have posted this over at the atmosphere mailing list https://groups.google.com/forum/#!topic/atmosphere-framework/TVF18UwYMD8 .
Stay tuned.

[teichsta]

thanks @digitaldan

[digitaldan]

I have not heard back from the Atmosphere guys, but given my little experiment with their sample app, I'm not confident it works how we think it does. I went ahead and closed my pull request.

I have modified the android client to work as expected when a connection is lost. My changes catch network exceptions and will schedule a reconnect after 10 seconds. This reconnect requests a fresh sitemap and then operates normally using long polling. It also handles canceling the reconnect when a fragment is paused. Its not a huge change, and works very well for me. I'm going to run it for a while and see. Take a look at: https://github.com/digitaldan/openhab.android/commit/d67a233372ff3eca1a33b01da8fe3b85165d63a3

Thoughts?

[digitaldan]

FYI, Jeanfrancois had me file a bug report, see Atmosphere/atmosphere#1655. I fear this might not get fixed quickly, but I'm going to keep looking at it from our end as well as the Atmosphere side.

[renatoriolino]

Hi,

I'm just an end-user and I don't know the dificult for it but I'll ask anyway: Is it possible to check what was the Atmosphere version used on openhab 1.3 and just stick with it by now? On 1.3 I never had problems with Atmosphere.

[]'s

Renato

2014-07-03 10:11 GMT-03:00 Dan notifications@github.com:

FYI, Jeanfrancois had me file a bug report, see Atmosphere/atmosphere#1655 https://github.com/Atmosphere/atmosphere/issues/1655. I fear this might not get fixed quickly, but I'm going to keep looking at it from our end as well as the Atmosphere side.

— Reply to this email directly or view it on GitHub https://github.com/openhab/openhab/issues/765#issuecomment-47927165.

[digitaldan]

So I just tried 1.3.1, it has all the same issues, plus a few more. I think why it appeared to be working was we were not using atmosphere the way it was intended, it did worked more reliably in one way, but also had the possibility of loosing events between requests. In essence, each request (from android for example) was creating a new atmosphere resource, which means the UUID broadcaster cache was not getting utilized between requests... I think... I'm new to this part of the code, so I'm still learning as I go.

I didn't run 1.3.1 at all, when I joined the project I started running 1.4.0 dev, so I do take everyone's word that it worked. I just don't see how we could go back, but I'm totally open to suggestions.

[digitaldan]

Hey guys, I leave for a week long vacation on Friday, so I'm going to be a little MIA from doing anything on this. There has been no update on the atmosphere bug. My plan was to lower the timeout on the server to something like a minute, and then lower the timeout on the client to something greater then that, say a minute and a half. This way the server would normally always close the connection and our client would be in a good state and just reconnect. If the client timed out first, then we would start a new connection a get the state all over again.

This is how the active sync protocol works, clients connect to exchange ( or gmail) over http and specify a timeout value, if the clients do not receive a connection close in that time frame they reconnect and offer a shorter timeout to the server. This is to handle unreliable wifi and cell networks.

[belovictor]

What is the current timeout in the server? Maybe I should just increase the timeout on both client apps then?

[digitaldan]

I have a version that has a 60 second timeout here: https://github.com/digitaldan/openhab/tree/rest-fixes-3

I have not set a slightly longer timeout in the android client. For some reason it seems to be timing out every 10 seconds even though I see in the code its set for something much longer.

[digitaldan]

OK, I think I have it working for android: https://github.com/digitaldan/openhab.android/tree/network-fixes

Server times out at 60 seconds, android at 65, all seems to be working so far.

[belovictor]

Hmm, I'm testing against demo.openhab.org and 300 seconds always get timeout on the client side :-/

[digitaldan]

I have not tested the client side timeout, I had assumed it was respecting the 65 second limit I set in my branch as before it was timing out in 10 seconds, which I know is the default value if non is set.

Have you tried with my latest branch for the server side timeout? That should be working fine, I'll play with the client some more and see why its not respecting that timeout.

[digitaldan]

So this is working for me, if I set the client to timeout at 30 seconds, and the server to 60, then the client always throws a java.net.SocketTimeoutException, which we catch and connect and get a new Id. If I have the client set to 65 and the server to 60 then the server always closes the connection which deliverers a empty response which we catch and reuse our existing id.

By the way I have just modified the OpenHABWidgetFragmentList class, I have not gone through to see if other classes were making long polling calls as well.

[belovictor]

How do you change the timeout on the server side?