Today, I started getting this error sporadically. Google pubsub error codes talks about only HTTP error codes. Does anyone know about this error?
ERROR Error: The service was unable to fulfill your request. Please try again. [code=8a75]
This error code is retryable, and can be safely expected. Automating your code to automatically retry with backoff, or to use one of the official client libraries, which automatically retry on these errors with backoff is the recommended solution.
In general these errors should be independent, meaning after a retry or two the odds that your RPC fails should be very low.
Related
I have developed an application in mule3 to transform data and then upload the data as a file to sftp location. I have included all common errors, such as http 400 series and 500 but what is a proper handling status code for when ftp fails, for example with file upload, connection or permission.
I have searched a lot on the internet and the more I search the more I get lost.
Does anyone have experience with this?
Thanks
If you are asking for a table for mapping error codes between SFTP and HTTP, there is no standard for it. These are completely different protocols. You have to define your own mapping. Most of them will probably be 5xx in HTTP, with authentication errors probably 403.
Not sure which connector version you use. But if you open the documentation of the SFTP connector, like: https://docs.mulesoft.com/sftp-connector/1.4/sftp-documentation.
You can see the documentation refers to the error that could be thrown, for example the copy operation can throw the following errors.
Based on those errors you should do your logic. Also the HTTP connector is throwing such errors, but then in the HTTP namespace. If needed you can also remap errors to a different and new namespace. Based on your remapped errors you could also implement logic.
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.
All of a sudden we are seeing this random error / exception in our web application.
Failed to load resource: the server responded with a status of 502 (Bad Gateway).
In the Log Stream, we are seeing the following details, with specific error code as 502.3 - Bad Gateway: Forwarder Connection Error (ARR).
Also, sometimes in the browser itself we see "The CGI application did not return a valid set of HTTP errors." getting displayed.
Most of the searches for these error codes refer to "IIS / Proxy Server" configuration. But, we haven't changed any such settings.
The error happens very randomly and not specific to any user action/function. Same functionality works first and on second execution immediately after first one throws this error.
How to figure out what is causing this and how to fix?
I google this question, because the program was normal at the beginning, and the subsequent 502.3 error. After I checked the information on the Internet, I feel that it can only give us an inspiration, and it cannot solve your problem immediately.
So my suggestion is that first you browse post1 and post2 I provided.
Next, proceed to Troubleshoot according to the steps of the official documentation. Specific errors require specific analysis.
In our software, we are keep getting this warning/error message intermittently. Not sure how/why this message appears.
HTTP asio handshake failed: error:140000DB:SSL routines:SSL
routines:short read
I searched in the Internet, but the mostly the result pointing me to a VMware problem. Which not the case for me.
Until I found out that actually this error is thrown by OpenSSL that is used by Boost-Asio. I have downloaded the source code of OpenSSL/Asio/Boost but couldn't find this error code in the source. My question, Is there anyone knows what this error means? What could be the trigger of this error message? I just want to understand a bit to find out the reproduction. So we can fix our software if there is any hole in the software.
Many Thanks in advance!
Reference:
http://ib-krajewski.blogspot.my/2016/03/https-support-for-casablanca-client.html
how to clean boost::asio::ssl::stream after closed by server
A commit in OpenSSL removed the error SSL_R_SHORT_READ.
The commit before before OpenSSL removed the error SSL_R_SHORT_READ still has it defined as 219 == 0xDB. This error of 0xDB is what comes out of OpenSSL as 0x140000DB.
In general a short read happens on TCP when the connection ended before the other side could send enough data to decode the current message. This may happen for example because the other side crashed or a network problem.
Found the root cause for my problem. There is mismatch of cipher the host and the client that trying to connect to. Then this error is thrown from the client.
I'm running an NServiceBus endpoint on an Azure Workerrole. I send all diagnostics to table storage at the moment. I was getting messages in my DLQ, and I couldn't figure out why I wasn't getting any exceptions logged in my table storage.
It turns out that NSB logs the exceptions as INFO, which is why I couldn't easily spot them in between all the actual verbose logging.
In my case, a command handler's dependencies couldn't be resolved so Autofac throws an exception. I totally get why the exception is thrown, I just don't understand why they're logged as INFO. The message ends up in my DLQ, and I only have a INFO-trace to understand why.
Is there a reason why exceptions are handled this way in NSB?
NServiceBus is not logging container issue as an error because it's happening during an attempt to process a message. First Level Retry and Second Level Retry will be attempted. When SLR is executed, it will log a WARN about the retry. Ultimately, a message will fail processing and an ERROR message will be logged. NSB and Autofac sample can be used to reproduce this.
When endpoint is running with a scaled out role and MadDeliveryCount is not big enough to accommodate all the role instances and retry count that each instance would hold, this will result in DeliveryCount reaching it's max while NServiceBus endpoint instance still thinks it has attempts before sending message to an error queue and logging an error. Similar to the question here I'd recommend to increase MaxDeliveryCount.
There is an open NServiceBus issue to have a native support for SLR counter. You can add your voice to the issue. The next version of NServiceBus (V6) will be logging message id along with the exception so that you at least could correlate between message in DLQ and log file.