Atmosphere loosing messages

[GoogleCodeExporter]

When a web socket enabled client connects to openHAB I can see messages like 
the following in my protocol:
o.a.cpr.DefaultBroadcaster[:533]- This message Entry{message=TestDimmer1 
(Type=DimmerItem, State=20.0), multipleAtmoResources=null, 
future=org.atmosphere.cpr.BroadcasterFuture@b6e838}

Like expected I can't receive any updates via WebSocket in any client app 
(GreenT, HABDroid, custom solution). This problem does not occur when forcing 
Atmosphere to use LongPolling (or just polling) for example via the use of a 
reverse proxy between the client and openHAB.
After some digging I dumped some tcp packets between openHAB and the client. In 
WebSocket mode a packet is sent when an update is expected, but the packet has 
a zero lentgh body, only some headers.

Original issue reported on code.google.com by till.klo...@gmail.com on 30 Apr 2013 at 12:05

[GoogleCodeExporter]

Oliver, is this something you could possibly analyze?

Original comment by kai.openhab on 30 Apr 2013 at 10:44

[GoogleCodeExporter]

I captured one of the packets I receive on the WebSocket connection. There are 
only headers and no body, so no information can be parsed:
 0x0000:  4500 0121 0e4f 4000 4006 e1b4 c0a8 644f  E..!.O@.@.....dO
        0x0010:  c0a8 6433 1f90 aa82 f0be 14cc c964 0eba  ..d3.........d..
        0x0020:  8018 0136 4ae7 0000 0101 080a 0247 e454  ...6J........G.T
        0x0030:  03f9 fbd2 4854 5450 2f31 2e31 2032 3031  ....HTTP/1.1.201
        0x0040:  2043 7265 6174 6564 0d0a 4461 7465 3a20  .Created..Date:.
        0x0050:  4d6f 6e2c 2032 3920 4170 7220 3230 3133  Mon,.29.Apr.2013
        0x0060:  2031 373a 3536 3a30 3720 474d 540d 0a58  .17:56:07.GMT..X
        0x0070:  2d41 746d 6f73 7068 6572 652d 7472 6163  -Atmosphere-trac
        0x0080:  6b69 6e67 2d69 643a 2064 6162 6132 3866  king-id:.daba28f
        0x0090:  332d 6231 3462 2d34 6434 352d 3935 6339  3-b14b-4d45-95c9
        0x00a0:  2d37 6337 3735 6437 6163 6662 380d 0a4c  -7c775d7acfb8..L
        0x00b0:  6f63 6174 696f 6e3a 2068 7474 703a 2f2f  ocation:.http://
        0x00c0:  6f70 656e 6861 623a 3830 3830 2f72 6573  openhab:8080/res
        0x00d0:  742f 6974 656d 732f 496e 7465 7274 6563  t/items/Intertec
        0x00e0:  686e 6f31 2f73 7461 7465 0d0a 436f 6e74  hno1/state..Cont
        0x00f0:  656e 742d 4c65 6e67 7468 3a20 300d 0a53  ent-Length:.0..S
        0x0100:  6572 7665 723a 204a 6574 7479 2838 2e31  erver:.Jetty(8.1
        0x0110:  2e33 2e76 3230 3132 3035 3232 290d 0a0d  .3.v20120522)...
        0x0120:  0a

Original comment by till.klo...@gmail.com on 1 May 2013 at 5:48

[GoogleCodeExporter]

I will investigate in this. 

Original comment by oliver.m...@gmail.com on 3 May 2013 at 9:34

[GoogleCodeExporter]

Till,

Does this behavior happen immediately or after the client sits idle for an 
extended period of time? 

I'm experiencing a similar issue where the Client stops receiving websocket 
updates after sitting overnight, but I haven't been able to figure out why.

Original comment by Amos.Kit...@gmail.com on 11 May 2013 at 12:48

[GoogleCodeExporter]

I left OpenHab running overnight on my LAN (14 hours) with a GUI which uses 
websockets for push updates. This morning I'm able to push buttons and see 
commands getting into OpenHab but the websockets connection has broken down so 
the GUI isn't updating. Running wireshark I can see that the only thing coming 
back from the openhab computer is HTTP ACK and TCP keep alive packets for the 
REST calls.

Looking in openhab.log I see that within a few hours of no buttons being 
pressed there are lots of these:
02:30:04.340 DEBUG o.o.i.r.i.b.GeneralBroadcaster[:61]- broadcaster 
'org.openhab.io.rest.internal.broadcaster.GeneralBroadcaster$1@2ac68235' is 
empty
02:30:04.341 DEBUG o.o.i.r.i.b.GeneralBroadcaster[:56]- broadcaster 
'org.openhab.io.rest.internal.broadcaster.GeneralBroadcaster$1@2ac68235' is idle
02:30:04.342 DEBUG o.o.i.r.i.b.GeneralBroadcaster[:72]- broadcaster 
'org.openhab.io.rest.internal.broadcaster.GeneralBroadcaster$1@2ac68235' 
destroyed

And these...

02:30:04.340 DEBUG o.o.i.r.i.b.GeneralBroadcaster[:61]- broadcaster 
'org.openhab.io.rest.internal.broadcaster.GeneralBroadcaster$1@2ac68235' is 
empty
02:30:04.341 DEBUG o.o.i.r.i.b.GeneralBroadcaster[:56]- broadcaster 
'org.openhab.io.rest.internal.broadcaster.GeneralBroadcaster$1@2ac68235' is idle
02:30:04.342 DEBUG o.o.i.r.i.b.GeneralBroadcaster[:72]- broadcaster 
'org.openhab.io.rest.internal.broadcaster.GeneralBroadcaster$1@2ac68235' 
destroyed

Is there anything else I can do the help figure out why websockets are breaking 
down?

Original comment by Amos.Kit...@gmail.com on 11 May 2013 at 6:11

[GoogleCodeExporter]

Sorry for my late answer. I will try to resolve the issue in the next two days.

Original comment by oliver.m...@gmail.com on 28 May 2013 at 11:21

[GoogleCodeExporter]

let me give you a short update. First i had to say that my planed bugfix 
doesn't work as expected so I had to reinvestigate. Moreover it seems that we 
have two different issues here. The one that Till posted, where Websocket 
support is completely broken and the other issue where openhab loses the 
connection after some hours of inactivity.
The first issue is possibly Network related. Seems that the server uses the 
first network adapter for the broadcasts. In my case (windows 7 x64) it's a 
virtual adapter (bridge) from my VPN software. If the VPN connection is 
established everything works as expected. But if the VPN is not connected the 
server still tries to use the Network adapter with the result that no broadcast 
reach the clients. Till, can you check your Network config?

Original comment by oliver.m...@gmail.com on 24 Jun 2013 at 12:12

[GoogleCodeExporter]

Hi Oliver,

I'm running openHAB on a Raspberry Pi, so my network configuration is pretty 
primitive.
Exactly it is configured like this:
eth0      Link encap:Ethernet  Hardware Adresse b8:27:eb:9b:ba:b2
          inet Adresse:192.168.xxx.xxx  Bcast:192.168.100.255  Maske:255.255.255.0
          inet6-Adresse: fe80::ba27:ebff:fe9b:bab2/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:377829 errors:0 dropped:0 overruns:0 frame:0
          TX packets:296555 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:80791019 (77.0 MiB)  TX bytes:166831790 (159.1 MiB)

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:31924 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31924 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:3145048 (2.9 MiB)  TX bytes:3145048 (2.9 MiB)

Except for the loopback device I have only one network device configured for my 
local network.

Original comment by till.klo...@gmail.com on 24 Jun 2013 at 12:19

[GoogleCodeExporter]

I also have this issue. I have 4 items updated "reasonably quickly" as polled 
SNMP GETs. The first 2 don't change value, so I can't see if they are updating, 
the third is working ok, but the 4th is not changing (I see the update in the 
debug console, but not in the GUI).

If I send a manual SNMP TRAP asynchronous to the polling, then this value does 
update. Changing to long polling also fixes the problem.

Looking at the network log in Chrome, there is only a single updated item 
coming through to the browser.

Original comment by ch...@cd-jackson.com on 31 Jul 2013 at 8:16

[GoogleCodeExporter]

Migrated to https://bugs.eclipse.org/bugs/show_bug.cgi?id=423509

Original comment by kai.openhab on 7 Dec 2013 at 9:01

• Changed state: Invalid