MULE-7809: Removing test for receivebuffersize. The value is just a sugg...

...estion, so the assertion fails on some environments.
There's no contract stating that the resulting value has to remain
unchanged. In fact, typical linux behaviour for larger than accepted by
kernel buffer sizes is to set the buffer to the max allowed size, which is
not the default nor the one passed as parameter.
So the test ends up being "check that it is the default value or the one
provided or any other value" which makes the test value arguable.




On Thu, Aug 14, 2014 at 5:24 PM, dfeist <notifications@github.com> wrote:

> In
> transports/http/src/test/java/org/mule/transport/http/HttpServerConnectionTestCase.java:
>
> > @@ -240,7 +239,6 @@ public void createHttpServerConnectionWithHttpConnectorProperties() throws Excep
> >          HttpConnector httpConnector = new HttpConnector(muleContext);
> >          httpConnector.setSendTcpNoDelay(SEND_TCP_NO_DELAY);
> >          httpConnector.setKeepAlive(KEEP_ALIVE);
> > -        httpConnector.setReceiveBufferSize(RECEIVE_BUFFER_SIZE);
>
> We don't know if it will use hint or not no, but there is still value in
> asserting the expected behaviour that you describe, that the size is either
> default socket buffer size or configured size. You might think this is of
> minimal value, but it covers regressions in
> HttpConnector/HttpServerConnection where the value of custom receive buffer
> size is propagated to socket.
>
> assertThat (conn.getSocketReceiveBufferSize(),
> anyOf(equalTo(RECEIVE_BUFFER_SIZE), equalTo(new Socket().
> getReceiveBufferSize)))
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/mulesoft/mule/pull/909/files#r16263715>.
>



-- 
*Pablo Abad*

Chief Architect | MuleSoft <http://www.mulesoft.com/>

Corrientes 316 EP | Buenos Aires, Argentina C1043AAQ


We're Hiring! <http://www.mulesoft.com/careers>


Try CloudHub - Integration Platform as a Service http://cloudhub.io