search

varamfer / openhab

Automatically exported from code.google.com/p/openhab
0 stars 0 forks source link

openHAB sometimes returns empty HTTP response (REST API) #66

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
openHAB sometimes returns empty HTTP responses. This happens only when a user 
access the Sencha Touch UI from a different machine than the openHAB runtime is 
installed (i.e. not localhost).

Original issue reported on code.google.com by mishoboss on 25 Jan 2012 at 2:17

GoogleCodeExporter commented 8 years ago 
Some additional info - the next long-poll request after the empty one returns 
the JSON data twice.

I think I have workarounded this issue in the Sencha UI, but it is definitely 
an openHAB runtime issue.

Original comment by mishoboss on 25 Jan 2012 at 2:53

GoogleCodeExporter commented 8 years ago

Original comment by kai.openhab on 31 Jan 2012 at 11:49

GoogleCodeExporter commented 8 years ago 
I guess this is related. This happens very often when a normal HTTP request is 
sent during a pending HTTP request of "long-poll" type.

15:09:59.007 WARN  o.o.i.r.i.l.TransportListener[:129] - Error in suspended 
request
javax.ws.rs.WebApplicationException: javax.xml.bind.MarshalException
 - with linked exception:
[javax.xml.stream.XMLStreamException: org.eclipse.jetty.io.EofException]
        at com.sun.jersey.core.provider.jaxb.AbstractRootElementProvider.writeTo(AbstractRootElementProvider.java:159)
        at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:306)
        at org.atmosphere.jersey.util.JerseyBroadcasterUtil.broadcast(JerseyBroadcasterUtil.java:59)
        at org.atmosphere.jersey.JerseyBroadcaster.broadcast(JerseyBroadcaster.java:58)
        at org.atmosphere.cpr.DefaultBroadcaster.executeAsyncWrite(DefaultBroadcaster.java:710)
        at org.atmosphere.cpr.DefaultBroadcaster$3.run(DefaultBroadcaster.java:747)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:636)
Caused by: javax.xml.bind.MarshalException: null
        at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:321)
        at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:161)
        at com.sun.jersey.json.impl.BaseJSONMarshaller.marshallToJSON(BaseJSONMarshaller.java:103)
        at com.sun.jersey.json.impl.provider.entity.JSONRootElementProvider.writeTo(JSONRootElementProvider.java:143)
        at com.sun.jersey.core.provider.jaxb.AbstractRootElementProvider.writeTo(AbstractRootElementProvider.java:157)
        ... 11 common frames omitted
Caused by: javax.xml.stream.XMLStreamException: 
org.eclipse.jetty.io.EofException
        at com.sun.jersey.json.impl.writer.JsonXmlStreamWriter.flush(JsonXmlStreamWriter.java:189)
        at com.sun.xml.internal.bind.v2.runtime.output.XMLStreamWriterOutput.endDocument(XMLStreamWriterOutput.java:96)
        at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.endDocument(XMLSerializer.java:843)
        at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.postwrite(MarshallerImpl.java:368)
        at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:315)
        ... 15 common frames omitted
Caused by: org.eclipse.jetty.io.EofException: null
        at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:919)
        at org.eclipse.jetty.http.AbstractGenerator.flush(AbstractGenerator.java:452)
        at org.eclipse.jetty.server.HttpOutput.flush(HttpOutput.java:89)
        at org.eclipse.jetty.server.HttpConnection$Output.flush(HttpConnection.java:995)
        at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:172)
        at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:96)
        at com.sun.jersey.spi.container.servlet.WebComponent$Writer.write(WebComponent.java:307)
        at com.sun.jersey.spi.container.ContainerResponse$CommittingOutputStream.write(ContainerResponse.java:134)
        at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:220)
        at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:290)
        at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:294)
        at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:140)
        at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
        at com.sun.jersey.json.impl.writer.JsonXmlStreamWriter.flush(JsonXmlStreamWriter.java:187)
        ... 19 common frames omitted
Caused by: java.io.IOException: Broken pipe
        at sun.nio.ch.FileDispatcher.write0(Native Method)
        at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
        at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:122)
        at sun.nio.ch.IOUtil.write(IOUtil.java:93)
        at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:352)
        at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:230)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:292)
        at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:295)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:269)
        at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:849)
        ... 32 common frames omitted

Original comment by mishoboss on 1 Feb 2012 at 1:17

GoogleCodeExporter commented 8 years ago 
LI will have a look on that issue

Original comment by oliver.m...@gmail.com on 1 Feb 2012 at 8:46

GoogleCodeExporter commented 8 years ago 
Any news about this?

Original comment by mishoboss on 9 Feb 2012 at 5:44

GoogleCodeExporter commented 8 years ago 
I'm still testing but you can expect the solution end of the week.

Original comment by oliver.m...@gmail.com on 10 Feb 2012 at 11:35

GoogleCodeExporter commented 8 years ago 
Hi mishoboss, Hi Kai
it is hard to reproduce the error but I think this error occures when the 
server lost the client connection or gets out of sync with the resources. It is 
possible that this behavior occurs due to timing problems inside atmosphere. 
During my testing I also noticed some other issues with the broadcaster and the 
resource lifecycle. I fixed this by adding a broadcaster lidecycle policy.

I think it's not the best approach to use the same endpoint address for "normal 
(REST)" and suspending resources. In the current setup we suspend each request 
first. This causes most of the current problems. I would suggest to separate 
the URLs. What do you think about this? 
Moreover I'll get in touch with the author from atmosphere framework and ask 
him for support.

Original comment by oliver.m...@gmail.com on 14 Feb 2012 at 4:50

GoogleCodeExporter commented 8 years ago 
Hi, Oliver. Thank you for the effort! I talk about a separate widget update URL 
for a long time. See this - http://code.google.com/p/openhab/issues/detail?id=56

In fact the whole mechanism for widget updates is not optimal. I think there 
must be a dedicated REST url for HTTP streaming (and respectively a socket url 
for the websocket streaming) that returns ONLY the changed widgets, not the 
whole page. Please, read issue 56 for more info on my ideas.

Original comment by mishoboss on 14 Feb 2012 at 5:11

GoogleCodeExporter commented 8 years ago 
Mihail, I think the successor of your suggestions of issue 56 is issue 62. In 
this issue 62, we intend to define a new content format that only returns you 
changed widgets that will have to be identified in some way. Oliver is well 
aware of issue 62 as it is assigned to him :-)

Original comment by kai.openhab on 14 Feb 2012 at 5:19

GoogleCodeExporter commented 8 years ago 
Oliver, I would like to release openHAB 0.9.1 as a patch release as soon as we 
consider this issue to be (at least partially) fixed.
So if you think you were able to improve the situation by adding the lifecycle 
policy, we could have a try with that.

> I think it's not the best approach to use the same endpoint address for 
> "normal (REST)" and suspending resources.
> I would suggest to separate the URLs. What do you think about this?

From an architectural (REST) point of view, it imho IS the best and cleanest 
approach - it is the same resource that is requested, the client just asks for 
a different way of processing - that's the purpose of HTTP request headers.
But from what we experience I agree with you that it technically does not seem 
to be the optimal (i.e. the one with the least problems) solution. So yes, for 
the 1.0.0 release let's discuss to define separate URIs for direct resp. 
polling requests.

Original comment by kai.openhab on 14 Feb 2012 at 5:26

GoogleCodeExporter commented 8 years ago 
hi Kai,
I check in my changes tomorrow evening till then I'll do some more stabillity 
tests.
If someone knows a test scenario which causes the "Error in suspended request" 
please let me know ;)

Original comment by oliver.m...@gmail.com on 16 Feb 2012 at 6:02

GoogleCodeExporter commented 8 years ago 
Hi,
as promised you can find my changes in my clone. 
Jeanfrancois Arcand pointed me to a solution for the suspend / not suspend 
dilemma.
It's not the most beautiful solution but it performs very well. In testing, the 
response times for non suspending requests improved up to 50 percent.

Original comment by oliver.m...@gmail.com on 17 Feb 2012 at 7:57

GoogleCodeExporter commented 8 years ago 
Hi Oliver!
Thanks a lot for the update, it is indeed an interesting idea to solve the 
non-suspending case by exceptions. If this works well, why not?
I have pulled your change and included it in the default branch.
@Mihail: Could you please test if this solves your problem with the empty 
responses (the latest snapshot build (166) already includes this fix)? If so, I 
would plan to release 0.9.1 in the next few days (possibly with an update of 
the Sencha Touch UI as well?).

Original comment by kai.openhab on 17 Feb 2012 at 10:42

GoogleCodeExporter commented 8 years ago 
Thanks, Oliver! I'm testing it now and so far it seems this issue is solved!

Kai, can you wait 4-5 days for the Sencha Touch UI? There are a lot of issues 
to solve as the new versions of Sencha Touch completely break the app.

Original comment by mishoboss on 18 Feb 2012 at 9:24

GoogleCodeExporter commented 8 years ago 
Oliver, it seems you terminate the suspended request on 1 minute timeout. Is 
this right? There is a little issue with that I have to resolve by me, as 
currently the app also has a timeout after which cancels the request and makes 
a new one.

Original comment by mishoboss on 18 Feb 2012 at 9:33

GoogleCodeExporter commented 8 years ago 
> Kai, can you wait 4-5 days for the Sencha Touch UI?

Sure, no problem.

Original comment by kai.openhab on 18 Feb 2012 at 10:30

GoogleCodeExporter commented 8 years ago 
Mihail, now with your new UI version, can we consider this issue to be tested 
successfully and do the 0.9.1 release?

Original comment by kai.openhab on 22 Feb 2012 at 8:57

GoogleCodeExporter commented 8 years ago 
I think this issue is gone. I test it two days with no problem so far. However 
there are several other issues, most of them are due to the update mechanism 
openHAB uses. I think we should concentrate on the Issue 62, so it will be done 
for version 1.0.

Original comment by mishoboss on 23 Feb 2012 at 9:18