I am using Apache CXF version 3.0.4 and while hitting my rest call getting 400 as Bad request and complete stack trace through which i was able to do further logic
Now when i have upgraded my cxf version to 3.2.1/3.2.6 then only in response i can see 400 bad request but that Stack trace missed and not showing any thing in response.
Can any one please tell what has been changed in 3.2.(Apache CXF).? or do i need to do add anything to get the same behavior?.
Take a look at org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper. Setting addMessageToResponse to true should help.
Related
we had a Mulesoft app that basically picks message from queue (ActiveMQ), then posts to target app via HTTP request to target's API.
Runtime: 4.3.0
HTTP Connector version: v1.3.2
Server: Windows, On-premise standalone
However, sometimes the message doesn't get sent successfully after picking from queue , and below message can be found in the log -
WARN 2021-07-10 01:24:46,080 [[masked-app].http.requester.requestConfig.02 SelectorRunner] [event: ] org.glassfish.grizzly.nio.transport.TCPNIOTransport: GRIZZLY0005: Can not set SO_KEEPALIVE to false
java.net.SocketException: Invalid argument: no further information
at sun.nio.ch.Net.setIntOption0(Native Method) ~[?:1.8.0_281]
The flow completed silently without any error after above message, hence no error handling happens.
I found this mentioning it is a known bug on Windows server and won’t affect the well behavior of the application, but the document is failing to set SO_KEEPALIVE to true rather than false.
Looks the message didn't get posted successfully as the target system team can't find corresponding incoming request in their log.
It is not acceptable as the message is critical and no one knows unless the target system realizes something is wrong... Not sure if the SO_KEEPALIVE is failing to be set to false is the root cause, could you please share some thoughts? Thanks a lot in advance.
The is probably unrelated to the warning you mentioned but there doesn't seem to be enough information to identify the actual root cause.
Having said that the version of the HTTP connector is old and it's missing almost 3 years of fixes. Updating the version to the last one should improve the reliability of the application.
I'm having a weird issue with Apache CXF and large (375MB) MTOM attachments are empty.
Running it locally in Eclipse produces the desired results, but deploying it to our server just gives an empty attachment.
The server is written in .NET and doesn't support chunking. With Chunking enabled the client works, but when i disable cunking it fails.
Sadly i'm unable to debug on the server, so i'm restricted to trace logging.
I've tried every trick i've been able to google.
Disable schema validation (CXF-4551) (CXF-7758)
Manually copying the file to java.io.tmpdir before sending, to ensure it can be read.
Custom DataSource
Disable WS-Security
Disable logging interceptor
Nothing seems to make a difference.
Every run i just get something like the following
</soap:Body></soap:Envelope>
--uuid:40ef745b-ac3c-4013-bbe7-a9cc28880423
Content-Type: application/xml
Content-Transfer-Encoding: binary
Content-ID: <7611ca0a-22f8-4637-b4f7-a5dfe7f20b81-3#www.somewhere.dk>
Content-Disposition: attachment;name="32_2018-03-28_output.xml"
--uuid:40ef745b-ac3c-4013-bbe7-a9cc28880423
Trying with a smaller (2KB) file on the server works just fine. A 75MB file gets attached correctly, but results in a HTTP 400 from the receiver (which i suspect is because the file is not fully transferred)
Does anyone have any ideas as to what might be causing this ?
After much trial & error, i finally managed to "solve" this. I enabled schema validation, and the data now appears. This is the exact issue that both bugs in my original question claims to fix.
Client client = ClientProxy.getClient(port);
BindingProvider bp = ((BindingProvider) port);
bp.getRequestContext().put("schema-validation-enabled", "true");
I can't add a comment so I'm posting this as an answer.
Jimmy could you perhaps comment on the latest CXF issue and provide some more details? Which version of CXF, what kind of client you are using, real code samples ideally, client logs?
Background
We have been running an application on JBoss that is exposed to the clients via an Apache Reverse Proxy. We recently introduced "HTTP 429 Too many requests" to slow down high velocity requests.
Problem
However, it seems that apache2 changes the HTTP status code from 429 to 500.
Root cause analysis
Confirmed from JBoss that it sends HTTP 429, by bypassing the proxy, and talking to it directly.
Confirmed from /var/log/apache2/access.log, that apache2 gets HTTP 429
10.0.0.161 - - [16/Jul/2014:07:27:47 +0000] "POST /the/URL/ HTTP/1.1" 429 1018 "-" "curl/7.36.0" |0/466110|
Curl Client gets 500, somehow.
There's also been a bug filed few years back on Bugzilla #900827. I remember reading that it has been fixed in 2.2.18. Yet, I still face the problem -- which leads me to think there's probably a different problem altogether.
Questions
As I have read elsewhere, Apache might not relay the code perfectly for custom HTTP status codes. But isn't HTTP 429 as a part of additional HTTP status codes RFC, a standard code enough to be recognised and relayed?
Is there something crucial that I am missing here?
PS: Since this question is more about HTTP status spec, I asked here. If the community feels its more about apache, please feel free to vote to move the question to Server Fault.
I just stumbled upon your question because i was once again researching a similar problem, where our Apache Reverse Proxy returned a 500 status code on an ActiveSync Response 449.
I also found the Bugzilla entry you mentioned and the statments that it should have been fixed with version 2.2.18, however we use 2.2.22 and still faced the problem.
After further reading into the comments in the Bugzilla entry which then lead to the apache bug entry #44995. Reading these comments, especially the last one lead me to the believe that the issue, especially with custom error codes without status message has not been fixed in any 2.2.x versions but is included in 2.3/2.4
So we moved on and updated our reverse proxy to a 2.4 version, and to our surprise the error code 449 was correctly passed over by the proxy.
As you didnt mentioned your apache2 version used, i can only guess that an update to 2.4 or 2.3 might be a possible solution for you.
I have a WCF service that among other bindings also uses WebHttpBinding for JSON inputs/results.
I made a custom IErrorHandler implementation in order to be able to set the StatusCode to 400 when something goes wrong and also return a JSON understandable message. It´s the straight implementation that you can find everywhere (nice way described here).
My problem is: when I test it locally using Visual Studio Web Development Server (Cassini) it works perfectly. However, when I deploy it to my test server (Windows 2008 with standard config for IIS and everything else) it does not work.
When I call it and debug with Firebug I get a HttpStatusCode 200 as a return and no response text. With Fiddler I get a HttpStatusCode 504 and no return at all. However, the behavior I expected (and what happens locally) is a call to the error callback of the ajax call with the responseText set.
I debugged it remotely and everything looks just fine. The execution pipeline is OK and all the classes are called as they should be just like they are locally, except it does not work.
Any suggestions? I´m pretty much out of options here to figure this out.
Thanks a lot!
if firebug and fiddler are giving different results, what happens if you telnet to it directly and perform a request (Something like:)
GET /VirtualDirectoryAndGetData HTTP/1.1
HOST: example.com
[carriage return]
It wouldn't surprise me if you're somehow getting odd headers/formatting back (to explain why firebug/fiddler disagree)
Another thing to test would be publishing to your dev machine to see if it's a machine-specific issue or a server vs dev webserver issue.
If it's happening anywhere outside VS, you might also try commenting out the lines where you set
rmp.StatusCode = System.Net.HttpStatusCode.BadRequest;
rmp.StatusDescription = "Bad request";
This may indicate whether it's a response code issue or an error handler issue.
If you can edit your question to include the results (with sensitive info removed), we'll see if we can track it down further.
Edit: after looking at the question again, it may well be that the server is erroring before it can send ANY response. FF might assume 200 by default, whereas ie might assume 504 (Gateway Timeout). This is total speculation but is possible. Do you see anything in the event logs?
I had a similar issue which I was able to solve. Take a look at the IIS settings. Details on how I overcame the issue are in this post: IErrorHandler returning wrong message body when HTTP status code is 401 Unauthorized
My code is consistently generating the following error:
org.apache.axis2.AxisFault: Timeout waiting for connection
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:203)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:76)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:400)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:225)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:435)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:402)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
After extensive searching the solution appears to be here:
http://amilachinthaka.blogspot.com/2009/05/improving-axis2-client-http-transport.html
Except I cannot access http client directly (that is done in auto generated code).
Instead I have tried:
http://wiki.apache.org/ws/FrontPage/Axis/AxisCommonsHTTP
Which seems to help slightly. However it only delays the problem I always get the timeout. Also the instructions appear to be for an old version of Axis since Axis2 does not have AxisProperties. I am using version 1.5.1. Any suggestions?
I think this was a bug, see here and has been fixed with Axis2 1.5.2 (at least for generated code). With custom code, you need to tackle this problem manually.