Project

General

Profile

2 issues after upgrade from 1.0 to 1.1

Igor Khomenko
Added about 4 years ago

We face 2 issues after upgrade from 1.0 to 1.1

We have next script

https://projects.tigase.org/boards/17/topics/4593

1) sometimes we get nothing in a response, in logs we see the next:

2015-03-20 18:27:02.274 [in_0-http]        AbstractMessageReceiver$QueueListener.run()  SEVERE: [in_0-http] Exception during packet processing: from=room1@muc.chat.my.com, to=http@ip-10-222-235-20.ec2.internal/6c6d9f85-ace0-42b8-bcd6-25397285c397, DATA=<iq from="room1@muc.chat.my.com" to="user1@room1@muc.chat.my.com" id="982013" type="result"/>, SIZE=127, XMLNS=null, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=result
java.io.IOException: stream is closed
    at sun.net.httpserver.Request$WriteStream.write(Request.java:383)
    at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
    at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
    at sun.net.httpserver.ExchangeImpl.sendResponseHeaders(ExchangeImpl.java:261)
    at sun.net.httpserver.HttpExchangeImpl.sendResponseHeaders(HttpExchangeImpl.java:86)
    at tigase.http.java.DummyServletResponse.getWriter(DummyServletResponse.java:88)
    at javax.servlet.ServletResponse$getWriter.call(Unknown Source)
    at tigase.http.rest.RestServlet$_execute_closure4.doCall(RestServlet.groovy:216)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
    at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at UpdateRoomOccupantsHandler$_closure1_closure2.doCall(UpdateRoomOccupantsREST.groovy:51)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
    at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at tigase.http.rest.ClosureCallback.onResult(ClosureCallback.groovy:37)
    at tigase.http.HttpMessageReceiver.processResultPacket(HttpMessageReceiver.java:359)
    at tigase.http.HttpMessageReceiver.processPacket(HttpMessageReceiver.java:260)
    at tigase.server.AbstractMessageReceiver$QueueListener.run(AbstractMessageReceiver.java:1424)

2) Change port doesn't work

we use next line to change port

--comp-name-3=http
--comp-class-3=tigase.http.HttpMessageReceiver
http/port[I]=8083

it worked with 1.0, but in 1.1 it isn't, it sets 8080 all the time


Replies (8)

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam about 4 years ago

1) This exception is caused by the fact that browser or other HTTP client closed HTTP request without waiting for HTTP response and XMPP response was received by HTTP API component after HTTP connection which started XMPP request was already closed by client. In this case I cannot think about anything else we could do instead of throwing exception.

The question is why HTTP client closed it's connection?

2) In version 1.1 we introduced some changes to how Tigase HTTP API component works internally which resulted also in some changes in configuration.

To set port on which HTTP API component listens for incoming HTTP requests in release 1.1 you need to put following line in your etc/init.properties file:

http/http/port[I]=8083

First http is name of component, and second http is name of property group.

Added by Igor Khomenko almost 4 years ago

Thanks

1) even with console tool curl I sometimes get the same result "Empty reply from server"

2) It works now

Added by Igor Khomenko almost 4 years ago

Here is my curl log:

* Hostname was NOT found in DNS cache
*   Trying 194.129.155.44...
* Connected to chatstage.ddn.com (194.129.155.44) port 8083 (#0)
> POST /rest/update_room_occupants HTTP/1.1
> User-Agent: curl/7.37.1
> Host: chatstage.ddn.com:8083
> Accept: /
> Content-Type: application/json
> Api-Key: token1
> Content-Length: 220
> 
* upload completely sent off: 220 out of 220 bytes
* Empty reply from server
* Connection #0 to host chatstage.ddn.com left intact
curl: (52) Empty reply from server

This happens like in 20% of requests

Added by Igor Khomenko almost 4 years ago

Do you have any thoughts on "Empty reply from server" issue?

Do you think it's 100% client side issue?

Added by Igor Khomenko almost 4 years ago

I realised that if I remove service.sendPacket call then it works pretty stable

Added by Igor Khomenko almost 4 years ago

So, with Jetty enabled server I got rid of this issue

http/http/server-class=tigase.http.jetty.JettyStandaloneHttpServer

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 4 years ago

I looked at your script from first post and I found what caused your issue. Issue is caused due to fact that in your script you set isAsync to false which means that your script needs to return response without waiting on answer, but calling service.sendPacket forces it to wait for answer (as closure passed to sendPacket method will be called when response will be received and will be executed to generate result). Due to that isAsync method needs to be set to true

Added by Igor Khomenko almost 4 years ago

wow, that makes sense, thank you

    (1-8/8)