I have request config set like below:
RequestConfig requestConfig = RequestConfig.custom()
.setConnectTimeout(5000)
.setSocketTimeout(10000)
.setConnectionRequestTimeout(5000).build();
Then using this config to submit a file to a server which will take up to a min to respond the file submission status. Executing this will throw java.net.SocketTimeoutException: Read timed out
After some experiments, I found out that:
When I set either connetTimeout or socketTimeout, the SocketTimeoutException will be thrown after the timeout I set for connectTimeout or socketTimeout.
When I set both connectTimeout and sockettimeout, the SocketTimeoutException will be thrown after the timeout I set for socketTimeout but not connectTimeout.
Can someone explain this?
I didn't expect setting the connetTimeout will throw the socketTimeout after the connectTimeout, because the client and server establish the connection in time. The server just takes time to process the request before responding.
Related
My server Hub is sending data to all clients continously. And my client appliction gets data.
$.connection.hub.url = "http://localhost:40874/signalr";
$.connection.hub.start();
var hub = $.connection.messages;
messages.client.newMessage = function(mes){ // show message }
When my server down, thi client side application console writes error.
GET http://localhost:60874/Api/Messages/GetMessages
net::ERR_CONNECTION_REFUSED
This message writes continously on console. I do not want to do this. It should write only one time.
And when I restart the server, the application does not listen anymore. I should refresh the client page. Why?
I am using reCaptch in my MVC 3 web app running in the localhost.
Things were working fine few weeks back but suddenly failing.
Suddenly getting this error.
if(!ReCaptcha.Validate(_config.RecaptchaPrivateKey)){ <-- times out here
//process other fields in the form
}
As soon as I fill the form and hot submit I get this error :
The operation has timed out
Description : An unhandled exception occurred during the execution of the current ...
Exception Details : System.Net.WebException: The operation has timed out
Is this a proxy issue?
Is this because my site on localhost runs on port 3316?
localhost:3316/user/signup
I saw some posts that suggests that reCAPTCHA expects port 80 but my app runs on port 3316
What can be the issue?
Thanks
I got around this by creating proxy class that inherits IWebProxy.
Then specifying to use this proxy when internal, I had to transform it out for other environments that didn't need to use it.
See this question and accepted answer:
Is it possible to specify proxy credentials in your web.config?
The above link took some finding, so I favourited it for future use.
I'm trying to get a client/server program exchanging http messages over ssl. To start, I created client and server programs that successfully exchange http requests using DefaultHttpRequest. The code that sends the request looks something like this:
HttpRequest request = new DefaultHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.POST, "https://localhost:8443");
ChannelBuffer buf = ChannelBuffers.copiedBuffer(line, "UTF-8");
request.setContent(buf);
request.setHeader(HttpHeaders.Names.HOST, host);
request.setHeader(HttpHeaders.Names.CONNECTION, HttpHeaders.Values.CLOSE);
request.setHeader(HttpHeaders.Names.CONTENT_TYPE, "text/xml");
request.setHeader(HttpHeaders.Names.CONTENT_LENGTH, Integer.toString(buf.capacity()));
ChannelFuture writeFuture = channel.write(request);
The client pipeline factory contains this:
pipeline.addLast("decoder", new HttpResponseDecoder());
pipeline.addLast("encoder", new HttpRequestEncoder());
// and then business logic.
...
The server pipeline factory contains this:
pipeline.addLast("decoder", new HttpRequestDecoder());
pipeline.addLast("encoder", new HttpResponseEncoder());
// and then business logic.
....
So far so good. Client sends, server receives and decodes the request. The messageReceived method on my handler is called with the correct data.
In order to enable the SSL, I've taken some code from the SecureChat example and added to both client and server pipeline factories:
For the server:
SSLEngine engine = SecureChatSslContextFactory.getServerContext().createSSLEngine();
engine.setUseClientMode(false);
pipeline.addLast("ssl", new SslHandler(engine));
// On top of the SSL handler, add the text line codec.
pipeline.addLast("framer", new DelimiterBasedFrameDecoder(
8192, Delimiters.lineDelimiter()));
For the client:
SSLEngine engine = SecureChatSslContextFactory.getClientContext().createSSLEngine();
engine.setUseClientMode(true);
pipeline.addLast("ssl", new SslHandler(engine));
// On top of the SSL handler, add the text line codec.
pipeline.addLast("framer", new DelimiterBasedFrameDecoder(
8192, Delimiters.lineDelimiter()));
Now when I send the request from the client, nothing seems to happen on the server. When I start up the applications, the server seems to connect (channelConnected is called), but when I send the message none of the data gets to the server (messageReceived is never called).
Is there something obviously wrong with what I am doing? Is this the way that https should work? Or is there a different method for sending http requests over ssl?
Thanks,
Weezn
You need to call SslHandler.handshake() on the client side. Check the example again its in there.
Oops, it seems like I copied and pasted too much from the SecureChat example.
Removing the DelimiterBasedFrameDecoder seems to fix the issue.
How can we make Pentaho retry rest requests on connection errors?
We have a Pentaho BI system which, among numerous data sources, is querying a particular REST api for over 20k query variations each run.
Predicatably, on most runs a few of these requests will fail due to connection hiccups. These usually manifest themselves in the Pentaho log as org.pentaho.di.core.exception.KettleException due to javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake, ultimately caused by java.io.EOFException: SSL peer shut down incorrectly.
After scouring the internet and Pentaho forums, we cannot find any instructions on adding a simple retry approach in cases such as this. Hair is being torn out.
Help me StackOverflow, you're my only hope!
Update 1:
Stacktrace:
ERROR 29-11 11:02:17,659 - B - org.pentaho.di.core.exception.KettleException:
Can not result from [https://<DOMAIN>/<PATH>?<PARAMS>]
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at org.pentaho.di.trans.steps.rest.Rest.callRest(Rest.java:190)
at org.pentaho.di.trans.steps.rest.Rest.processRow(Rest.java:385)
at org.pentaho.di.trans.step.RunThread.run(RunThread.java:40)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at com.sun.jersey.client.apache.DefaultApacheHttpMethodExecutor.executeMethod(DefaultApacheHttpMethodExecutor.java:213)
at com.sun.jersey.client.apache.ApacheHttpClientHandler.handle(ApacheHttpClientHandler.java:175)
at com.sun.jersey.api.client.filter.HTTPBasicAuthFilter.handle(HTTPBasicAuthFilter.java:81)
at com.sun.jersey.api.client.Client.handle(Client.java:648)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:670)
at com.sun.jersey.api.client.WebResource.get(WebResource.java:191)
at org.pentaho.di.trans.steps.rest.Rest.callRest(Rest.java:141)
... 3 more
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:817)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:632)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpConnection.java:827)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.flushRequestOutputStream(MultiThreadedHttpConnectionManager.java:1525)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1975)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at com.sun.jersey.client.apache.DefaultApacheHttpMethodExecutor.executeMethod(DefaultApacheHttpMethodExecutor.java:210)
... 9 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:333)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
... 22 more
or use step error handling on the rest client step, and direct the error fields to another rest client step.
obviously that only lets you retry as many times as you have steps, but there's no point retrying more than once anyway.
Use the source, Luke.
In org.pentaho.di.trans.steps.rest.Rest.processRow(Rest.java:385) you will find
} catch(KettleException e) {
boolean sendToErrorRow=false;
String errorMessage = null;
if (getStepMeta().isDoingErrorHandling()){
sendToErrorRow = true;
errorMessage = e.toString();
} else {
logError(BaseMessages.getString(PKG, "Rest.ErrorInStepRunning")+e.getMessage()); //$NON-NLS-1$
setErrors(1);
logError(Const.getStackTracker(e));
stopAll();
setOutputDone(); // signal end to receiver(s)
return false;
}
if (sendToErrorRow) {
// Simply add this row to the error row
putError(getInputRowMeta(), r, 1, errorMessage, null, "Rest001");
}
}
It appears that you can configure error-handling on a row-basis. This seems to be what you are after.
Can someone help me with this problem that occurs whenever you run a TRIGGER, but works in a normal PROCEDURE?
TRIGGER:
create or replace
procedure testeHTTP(search varchar2)
IS
Declare
req sys.utl_http.req;<BR>
resp sys.utl_http.resp;<BR>
url varchar2(500);
Begin
url := 'http://www.google.com.br';
dbms_output.put_line('abrindo');
-- Abrindo a conexão e iniciando uma requisição
req := sys.utl_http.begin_request(search);
dbms_output.put_line('preparando');
-- Preparandose para obter as respostas
resp := sys.utl_http.get_response(req);
dbms_output.put_line('finalizando response');
-- Encerrando a comunicação request/response
sys.utl_http.end_response(resp);
Exception
When Others Then
dbms_output.put_line('excecao');
dbms_output.put_line(sys.utl_http.GET_DETAILED_SQLERRM());
End;
close your user session and then the problem is fixed.
Internal there is a limit from 5 http requests.
Might a problem is the missing: utl_http.end_response
or an exception in the app and not a close from the resp object.
modify the code like that:
EXCEPTION
WHEN UTL_HTTP.TOO_MANY_REQUESTS THEN
UTL_HTTP.END_RESPONSE(resp);
you need to close your requests once you are done with them, it does not happen automatically (unless you disconnect form the db entirely)
It used to be utl_http.end_response, but I am not sure if it is the same api any more.
Usually we need UTL_HTTP.END_RESPONSE(resp); to avoid of ORA-29270: too many open HTTP requests, but I think I reproduced the problem of #Clóvis Santos in Oracle 19c.
If web-service always returns status 200 (success) then too many open HTTP requests never happens. But if persistent connections are enabled and web-service returns status 404, behavior becomes different.
Let`s call something that always return 404.
First call of utl_http.begin_request returns normally and opens new persistent connection. We can check it with select utl_http.get_persistent_conn_count() from dual;. Second call causes an exception inside utl_http.begin_request and persistent connection becomes closed. (Exception is correctly handled with end_response/end_request).
If I continue then each odd execution returns 404 normally and each even execution gives an exception (handled correctly of course).
After some iterations I get ORA-29270: too many open HTTP requests. If web-service returns status 200 everything goes normally.
I guess, it happens because of the specific web-service. Probable it drops persistent connection after 404 and doesn't after 200. Second call tries to reuse request on persistent connection but it doesn't exist and causes request leak.
If I use utl_http.set_persistent_conn_support (false, 0); once in my session the problem disappears. I can call web-service as many times as I need.
Resolution:
Try to switch off persistent connection support. Probable, on the http-server persistent connections work differently for different requests. Looks like a bug.