Redlab's explorations and findings of the whole wide world
I’ve recently conducted a survey about logging. Whilst it’s not a complete correct survey ( I left out Log4j2 oops! Sorry, next time better! And I will definitely try it out )
You can now follow up on the results here on RebelLabs , they gave me the opportunity to post the results there. And so I did. Head over to RebelLabs and read the summary!
Ever wanted to return obscure HTTP Status codes from your Jersey REST application?
Now you can easily get all HTTP Status codes from the 7XX ranged as proposed by some people at RailsCamp ( see spec ) just grab the status codes from here at github or pull em in as maven dependency with
<dependency>
<groupId>be.redlab.jersey</groupId>
<artifactId>http-7xx</artifactId>
<version>1.0</version>
</dependency>
You can just send it with Jersey’s response like return
Response.status(HttpStatus7xx.A_KITTEN_DIES).build(); |
I know that Tomcat will not send the reason phrase. By default tomcat does not allow to set custom messages for statusses. To get tomcat to send the custom message you have to add a parameter at startup set
-Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=true
and you will have the status message in your response.
I haven’t tested with other containers yet.
Have fun with 7XX !
Last two weeks our operations team had to do daily restarts of a site that has between 800K to 1M hits per day. At a certain point, the webservers couldn’t take more connections, died and had to be restarted.
To detect the problem they tried to simulate the same behaviour on an a staging environment but we never succeeded in bringing those down. It took the team two weeks to simulate the exact same behaviour. Which in fact was a combination of a back end search service that performed a re-indexing operation and a bug in the client used to request data from that engine. ( A search request to the search engine happens with 7 on 10 of the hits)
At a certain point of the indexing the search engine started to spit out exceptions responses instead of the only expected result response. The application code that requests data from that search engine was recently changed to use a pool of JAXB Unmarshallers from javax.xml.bind.JAXBContext instead of creating new unmarshallers on the fly.
As you may know, or may not know and then you know now, Continue reading “Watch out when you pool things!”