I have been using spring boot with stomp server for websocket with sockjs as frontend library. Intermittently I get the following message in the logs.
11:10:15.017 [37] [http-nio-8080-exec-7] WARN org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver - Resolved [org.springframework.http.converter.HttpMessageNotWritableException: No converter for [class java.util.LinkedHashMap] with preset Content-Type 'application/javascript;charset=UTF-8']
As far as I have read this occurs when wrong content type is recieved in controller. But this data comes in through websocket and all the data is made to string using JSON.Stringify from frontend and recieved by #MessageMapping annoted controller. Iam not able to understand why this error occurs , could there be other reasons for this issue to occur. I have used ActiveMQ as the message broker.
Can someone throw some light into what could be happening here.
I figured out the issue myself. Issue occurs when the stomp server try to send heart beat from server to client. If the client disconnects while the server is sending the heartbeat, the issue occurs.
Related
I am getting error 503 service unavailable upstream connect error or disconnect/reset before headers. reset reason: local reset while making a rest call in my spring boot microservice. I am using Istio as API gateway.
Any help would be appreciated.
Found the issue in istio api url. It was not configured properly.
I have a very strange scenario where, in a Linux server, CURL successfully retrieves a response from a web service. When that same request is issued by Tomcat on the same linux server used for the CURL command, for some reason Tomcat receives a 400 status code, which prevents me from doing our business logic.
Flow with CURL:
CURL issues request to Service A using Proxy A
Service A retrieves the data we need and returns it, as well as a 200 Status Code
CURL receives the correct data and 200 status code...
Flow with Tomcat:
Tomcat issues request to Service A using Proxy A
Service A retrieves the data we need and returns it, as well as a 200 Status Code
Tomcat receives a 400 status code and is not able to receive the correct data...
What could be causing this problem? Tomcat and CURL are using the same proxy and are in the same linux server... even the service is able to fetch the data successfully and return it to both. Only in the case of tomcat, the service is throwing this error after trying to write the data in the response:
2021-03-10 21:49:36.908 WARN 90623 --- [https-jsse-nio-8123-exec-10] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved [org.springframework.http.converter.HttpMessageNotReadableException: I/O error while reading input message; nested exception is org.apache.catalina.connector.ClientAbortException: java.net.SocketTimeoutException]
Tomcat closes the socket because it sees a 400 response code, and doesn't even try reading the bytes from the response when I do con.getInputStream(). I don't really know where that 400 Status code is coming from.
Any help is appreciated. Thanks.
UPDATE 2021/03/11:
One thing I forgot to mention is that, Tomcat is able to perform other requests to that same service. The main difference here is the size of the response. It timesout when trying to read this large response, in comparison to other smaller responses we get.
UPDATE 2021/03/16:
After investigating deeper on what is happening I found out that, whenever I issue the request with Java, for some reason it timesout at exactly 2 minutes. That doesn't happen with CURL, only with Java. Is there anything I may be missing? I have already added these to my code:
JVM Arguments:
-Dsun.net.client.defaultReadTimeout=6000000 -Dsun.net.client.defaultConnectTimeout=6000000
Java code
con.setReadTimeout(Integer.MAX_VALUE);
con.setConnectTimeout(Integer.MAX_VALUE);
con.setDoOutput(true);
con.setDoInput(true);
I'm using an HttpURLConnection object.
http.converter.HttpMessageNotReadableException
The message that your tomcat sends to the service can not be read. Something happens with the message that your tomcat sends to the service. Does it have a json body included? If yes check that model class how it is serialized.
When the REST client call to a non existet context in my REST service app, the WebSphere Liberty server sends a custom CONTEXT_ROOT_NOT_FOUND error that I would like to replace with my own custom error message.
I tried with FallbackHandler and ExceptionMapper mechanisms (Microprofile technology) but none of them are capturing the error so I'm unable to replace the response.
Does exist any other mechanism to capture this error before it is sent to the client?
What is happening is your application is bound to a context root so requests outside the context root are resolving to a 404 by the server because there is no server there. The simplest solution would be to bind your application to the root context which can be done like this:
<webApplication location="my.app.war" contextRoot="/" />
When I make a rest request and server throws an application exception like IllegalArgumentException, I get response with http status 404.
Wouldn't a response with http status 500 be better?
Or what would actually be the expected response when an application exception is thrown? Is there some default behaviour in resteasy, spring or tomcat itself?
I know I can use an ExceptionMapper for resteasy, but is this really best practice or is there a better alternative?
I'm using following setup:
spring
resteasy
tomcat 7
Update:
The problem I'm facing is that I have 2 web applications, one is returning http status 500 and the other is returning http status 400 when an IllegalArgumentException is thrown. I can't figure out why they behave different. It seems to me, that both web application have the same spring and resteasy configuration.
When I'm debugging, I see that resteasy is transforming the IllegalArgumentException to a org.jboss.resteasy.spi.UnhandledException, but the response and the response status code, respectively, is not touched.
So besides not knowing which http status code would be the expected one (400, as Jon Skeet and Stefano Cazzola already pointed out), I didn't know either why the 2 web applications behaves different.
I couldn't find any resteasy ExceptionMapper in both web application.
So is there some default behavior in resteasy, spring or tomcat, which is mapping an IllegalArgumentException to http status 404 or http status 500? Or how can this happen?
The response code is correlated to the error happened in the server. If the error is related to an invalid input received from the client, then the formally correct response status is 400 (Bad Request). The difference with 500 is that returning 400 is the correct behaviour for the server: means, the server processed correctly and responded with an error because the request was wrong. If the same request will ever be resubmitted, it will receive the same error response. The server is not supposed to correct this error, it is up to the client.
You can take this link as a reference
The pubsub example of atmosphere is deployed to weblogic 12c.
with the below small change i deployed the app
var request = {
url :document.location.toString()+'ws/pubsub/' + getElementByIdValue('topic'),
Gives the following error...
On server side
org.atmosphere.websocket.protocol.SimpleHttpProtocol BEA-000000 Status code higher or equal than 400 Status 405 Message Method Not Allowed
In script console(chrome)
Network
ERROR: 405:Method Not Allowed
ERROR: 405:Method Not Allowed
message=testing pubsub sent trying to use websocket
console
GET =1396276957934">http://localhost:7001/atmosphere/ws/pubsub/Test?X-Atmosphere-Transport=close&X-Atmosphere-tracking-id=&=1396276957934 400 (Bad Request) atmosphere.js:1816
WebSocket connection to 'ws://localhost:7001/atmosphere/ws/pubsub/Test?X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.1.4-javascript&X-Atmosphere-Transport=websocket&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&X-atmo-protocol=true' failed: Received a broken close frame containing a reserved status code.
Solved
document.location.toString()
needs to be modified to
document.location.origin+'/atmosphere/ws/pubsub/'
to skip the name of the html file(if not index.html) .
The atmosphere handler will take care of the operation and connects to websockets as intended.
The long polling needs to be addressed as a seperate url , as the weblogic-12c adds /ws/ to context path automatically, when it detects websocket stuff
refer to
complete solution