Closed GoogleCodeExporter closed 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
Original comment by kai.openhab
on 31 Jan 2012 at 11:49
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
LI will have a look on that issue
Original comment by oliver.m...@gmail.com
on 1 Feb 2012 at 8:46
Any news about this?
Original comment by mishoboss
on 9 Feb 2012 at 5:44
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
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
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
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
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
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
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
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
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
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
> 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
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
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
Original issue reported on code.google.com by
mishoboss
on 25 Jan 2012 at 2:17