I have a Tomcat based web application. I am intermittently getting the following exception,
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:532)
at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:501)
at org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:563)
at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:124)
at org.apache.coyote.http11.AbstractInputBuffer.doRead(AbstractInputBuffer.java:346)
at org.apache.coyote.Request.doRead(Request.java:422)
at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:290)
at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:431)
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:315)
at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:200)
at java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:385)
Unfortunately I don’t have access to the client, so I am just trying to confirm on various reasons this can happen,
-
Server is trying to read data from the request, but its taking longer than the timeout value for the data to arrive from the client. Timeout here would typically be Tomcat connector → connectionTimeout attribute.
-
Client has a read timeout set, and server is taking longer than that to respond.
-
One of the threads I went through, said this can happen with high concurrency and if the keepalive is enabled.
For #1, the initial value I had set was 20 sec, I have bumped this up to 60sec, will test, and see if there are any changes.
Meanwhile, if any of you guys can provide you expert opinion on this, that’l be really helpful. Or for that matter any other reason you can think of which might cause this issue.
double-beep
4,85916 gold badges32 silver badges41 bronze badges
asked Jun 13, 2013 at 4:30
1
Server is trying to read data from the request, but its taking longer than the timeout value for the data to arrive from the client. Timeout here would typically be tomcat connector -> connectionTimeout attribute.
Correct.
Client has a read timeout set, and server is taking longer than that to respond.
No. That would cause a timeout at the client.
One of the threads i went through, said this can happen with high concurrency and if the keepalive is enabled.
That is obviously guesswork, and completely incorrect. It happens if and only if no data arrives within the timeout. Period. Load and keepalive and concurrency have nothing to do with it whatsoever.
It just means the client isn’t sending. You don’t need to worry about it. Browser clients come and go in all sorts of strange ways.
answered Jun 13, 2013 at 5:45
6
Here are the basic instructions:-
- Locate the «server.xml» file in the «conf» folder beneath Tomcat’s base directory (i.e.
%CATALINA_HOME%/conf/server.xml
). - Open the file in an editor and search for
<Connector
. - Locate the relevant connector that is timing out — this will typically be the HTTP connector, i.e. the one with
protocol="HTTP/1.1"
. - If a
connectionTimeout
value is set on the connector, it may need to be increased — e.g. from 20000 milliseconds (= 20 seconds) to 120000 milliseconds (= 2 minutes). If noconnectionTimeout
property value is set on the connector, the default is 60 seconds — if this is insufficient, the property may need to be added. - Restart Tomcat
answered Sep 19, 2018 at 13:10
Steve ChambersSteve Chambers
35.5k21 gold badges151 silver badges203 bronze badges
Connection.Response resp = Jsoup.connect(url) //
.timeout(20000) //
.method(Connection.Method.GET) //
.execute();
actually, the error occurs when you have slow internet so try to maximize the timeout time and then your code will definitely work as it works for me.
answered Mar 5, 2019 at 15:09
1
I had the same problem while trying to read the data from the request body. In my case which occurs randomly only to the mobile-based client devices. So I have increased the connectionUploadTimeout
to 1min as suggested by this link
answered Dec 4, 2020 at 17:23
I have the same issue. The java.net.SocketTimeoutException: Read timed out error happens on Tomcat under Mac 11.1, but it works perfectly in Mac 10.13. Same Tomcat folder, same WAR file. Have tried setting timeout values higher, but nothing I do works.
If I run the same SpringBoot code in a regular Java application (outside Tomcat 9.0.41 (tried other versions too), then it works also.
Mac 11.1 appears to be interfering with Tomcat.
As another test, if I copy the WAR file to an AWS EC2 instance, it works fine there too.
Spent several days trying to figure this out, but cannot resolve.
Suggestions very welcome!
answered Jan 31, 2021 at 13:38
MorkusMorkus
4876 silver badges19 bronze badges
1
This happenned to my application, actually I was using a single Object which was being called by multiple functions and those were not thread safe.
Something like this :
Class A{
Object B;
function1(){
B.doSomething();
}
function2(){
B.doSomething();
}
}
As they were not threadsafe, I was getting these errors :
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketException: Socket is closed
and
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out
This is how I fixed it :
Class A{
function1(){
Object B;
B.doSomething();
}
function2(){
Object B;
B.doSomething();
}
}
Hope it helps
answered Jun 22, 2022 at 10:27
It means time out from your server response. It causes due to server config and internet response.
answered Mar 20, 2021 at 15:32
I am using 11.2 and received timeouts.
I resolved by using the version of jsoup below.
<dependency>
<groupId>org.jsoup</groupId>
<artifactId>jsoup</artifactId>
<version>1.7.2</version>
<scope>compile</scope>
</dependency>
entpnerd
9,6897 gold badges44 silver badges67 bronze badges
answered Feb 7, 2018 at 14:40
Timeout errors are troublesome, isn’t it?
Apache Tomcat session timeout mainly occurs due to longer idle sessions. But, finding the real reason for the timeout error can be tricky.
At Bobcares, we receive many requests to fix the Apache Tomcat session timeout error as part of our Server Management Services.
Today let’s have a deep look at this error and how our Support Engineers fix it for the customers.
What is the Apache Tomcat session timeout error?
Recently, one of our customers approached us with a session time out error.
He had web applications running under Apache Tomcat Webserver. He left his application idle for about 30 minutes.
After that, when he tried to access the page, he got the following error,
This occurred due to the idle session timeout error of an application server.
Usually, the default session timeout in the Apache Tomcat application server is 30 minutes. Unless it is set as per the application requirement, it can result in website errors.
How we change the session timeout value?
Now let’s check how our Support Engineers change the session timeout setting for an Apache Tomcat application server.
To modify the default session timeout value on an Apache Tomcat server,
1. Firstly, we open the web.xml file within the Tomcat installation directory. For security reasons, we always make a backup copy of this file.
Usually, in Windows, web.xml file appears under the path c:Program FilesApache Software FoundationTomcat x.0conf.
Similarly, in Linux, we can edit this file from /opt/tomcat/conf/web.xml.
2. After that, we edit the following segment of code in the web.xml file,
30
3. Next, we change the timeout setting to the desired value. It is important to note that the value of timeout is set in minutes.
4. Finally, we save the file and restart the Tomcat server.
Similarly, we can set up an unlimited session timeout or no timeout in Tomcat. We can do this by setting the number in the session timeout tag to -1.
But, we do not recommend this due to security reasons. An attacker can steal and use the existing user session during this session timeout.
Therefore, setting the session timeout value to a minimum is the best practice.
[Need help to change the Tomcat session timeout value?- We’re available 24/7.]
Conclusion
In short, the login screen appears frequently due to the idle session timeout of the Application Server. Today, we saw how our Support Engineers fix the Apache Tomcat session timeout error for our customers.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
Introduction to tomcat timeout
When there are long idle sessions where nothing is happening, the tomcat webserver raises the session timeout after a certain period, leading to the closing of the session waiting time. The configuration of this timeout parameter is specified in the web.xml file present inside the tomcat installation home path. We can change the value by changing the attribute’s value in web.xml. One of the tricky things is to find the reason behind the timeout error, which we will try to understand in this session.
In this article, we will individually discuss the things of tomcat timeout and timeout error.
What is tomcat timeout?
Tomcat timeout is the configuration setting specified in web.xml, which helps determine the maximum time the server should wait in a particular idle session with none of the process happening inside it. It is always a good practice to close this session for the benefits of maintaining security over the session and also the management of memory. After this idle time, the tomcat webserver raises a session timeout error, and the person is navigated out of the session.
tomcat timeout configure session
The configuration of the session timeout attribute can be found in the web.xml file of the tomcat server. This file can be located inside the home directory of tomcat installation and the conf folder. Usually, in windows, the file is present in the C drive’s Program Files/ Apache Software Foundation/ Tomcat (version installed)/ conf folder. In the Linux platform, the file can be found inside the /opt/ tomcat (version installed), inside which you will find the conf folder inside which the web.xml file will be there.
The default value of session-timeout set for Apache Tomcat Web /server is 30 minutes specified between the starting and ending element of <session-timeout > element inside the web.xml file.
tomcat timeout configures session error
Usually, when our application takes a long time to retrieve the response and the browser does get the response from the webserver in a stipulated time of the session time out, then an error named session timeout is thrown on the user’s side, and the user is navigated back to the login page as can be seen from the below screenshot –
Usually, when your request to bring certain data or perform certain manipulation may take a long time due to huge data or improper management in coding the feature, the best solution is to increase the session timeout value set in the tomcat configurations. Hence, avoiding the session timeout error when your feature will take a long time to become successful can be done by manipulating the session timeout value of the tomcat web server’s configurations.
Changing the existing or default value of session timeout is easy and can be understood from the below point.
We change the session timeout value.
The default value set for the tomcat session timeout is 30 minutes, meaning that the application will wait for a minimum of 30 minutes to get the response to its request, and if the response doesn’t come, the session is considered timed out, and it is closed. We can change the default value of tomcat session timeout simply by editing a configuration file named web.xml in which the element with tag <session-timeout> needs to be searched and modified. The tag will, by default, be as shown below –
<session-config>
<session-timeout> 30 </session-timeout>
</session-config>
You can set any desired value between the starting and ending tag of session-timeout in web.xml and then save the file. Note that the value should be mentioned considering the unit as minutes. After saving your changes to reflect the configurations, you need to restart the Apache Tomcat web server. You can find the web.xml file of configurations in the path <Catalina tomcat installation home>/conf, where the Catalina tomcat installation home is the directory where you have installed your Apache Tomcat in the system.
It is always suggested to take the backup of the existing web.xml file before you make any changes to it. This is just in case the configurations you set or modify in the file do not work out as expected; then, you can revert the file to the previously provided if you have a backup.
We can also set the unlimited timeout configuration for the session or mean no timeout of sessions in tomcat by changing the value mentioned in the session-timeout element of web.xml to -1. Though doing so is not suggested, your session details may then get accessible by the attacker, which will lead to leakage of information about your credentials and related applications. Hence, for security reasons, never set the value to unlimited timeout.
tomcat timeout examples
Let us first understand the need to change the timeout value of tomcat using an example. If the specified timeout value is over, the session is closed, and the user is again brought back to the login page to initiate a new session, as shown in the below screen –
The default value set as timeout may result in a problem in some scenarios when a request from your application takes the time to return a response greater than the set timeout value. Unfortunately, this results in the user being unable to use that functionality. However, we can overcome this problem simply by changing the value of the timeout set inside the configuration file of the tomcat web server.
First, open the web.xml file and search for the session-timeout element. It looks by default as shown here –
If I know that my request will take 45 minutes to serve. With a safer value considering the worst-case scenarios of the network, let’s set the value to 50 minutes inside the web.xml as shown below –
After doing so, my feature will work properly and perform the necessary task without exiting the session.
Conclusion
Tomcat timeout or session timeout is the value for which a particular session on the browser side waits until it gets the response from the server. We can manipulate this value from configurations.
Recommended Articles
This is a guide to tomcat timeout. Here we discuss each of the things of tomcat timeout and timeout error individually. You may also have a look at the following articles to learn more –
- What is Apache Tomcat?
- Spring Boot Tomcat
- Spring Boot Docker
- Apache POI
- HowTo
- Java Howtos
- Java.Net.SocketTimeoutException: Read …
java.net.SocketTimeoutException: Read timed out
- Causes of
java.net.SocketTimeoutException: Read timed out
- Solution to
java.net.SocketTimeoutException: Read timed out
Today’s tutorial will discuss potential reasons and solutions for the java.net.SocketTimeoutException: Read timed out
under Tomcat in Java.
java.net.SocketTimeoutException: Read timed out
java.net.SocketTimeoutException: Read timed out
occurs when the server attempts to read data from the request; however, it is taking far longer than the allowed amount of time for the data to arrive from the client. The timeout
option can have a developer’s default value pre-set for client and server activities.
Causes of java.net.SocketTimeoutException: Read timed out
The following are some potential causes that could result in java.net.SocketTimeoutException: Read timed out
:
- The server is trying to read data from the request; however, it is taking significantly more than the specified amount of time for the data to arrive from the client.
Timeout
in this context is often represented by thetomcat connector -> connectionTimeout attribute
. - When there is a lot of concurrent activity, this error can occur if the
keepalive
feature is turned on. - It occurs if no data arrives before the timeout expires.
- When the server has slow performance.
Solution to java.net.SocketTimeoutException: Read timed out
-
The modification of the
.xml
context file and theCONNECTOR
definition, which controls the connectivity of the workstation browser to the Tomcat server, is one approach that might be taken to resolve this issue inside the context of the Tomcat web application. -
To be more concise, adjust the value of the
connectionTimeout
property. Raising this value will prevent the error condition from occurring. -
For example, we have the following
.xml
file containing the below data:<Connector executor="tomcat" port="8080" protocol="HTTP/1.1" connectionTimeout="30000" redirectPort="8443" />
-
To disable the upload timeout and cancel the read-write connection timeout setting, we can add
disableUploadTimeout= "false"
.<Connector executor="tomcat" port="8080" protocol="HTTP/1.1" connectionTimeout="30000" disableUploadTimeout="false" redirectPort="8443" />
-
We can also increase the connection lifespan by including the
keepAliveTimeout= "200000"
parameter.<Connector executor="tomcat" port="8080" protocol="HTTP/1.1" connectionTimeout="30000" keepAliveTimeout= "200000" redirectPort="8443" />
I have been working as a Flutter app developer for a year now. Firebase and SQLite have been crucial in the development of my android apps. I have experience with C#, Windows Form Based C#, C, Java, PHP on WampServer, and HTML/CSS on MYSQL, and I have authored articles on their theory and issue solving. I’m a senior in an undergraduate program for a bachelor’s degree in Information Technology.
Related Article — Java Error
I’m just going to assume you are using Linux/Unix (includes telnet and netstat)… and that you run on port 8080. (Please edit your post, and add this info; and then if I guessed correctly, remove this notice on my answer)
Check that tomcat is listening as expected:
$ netstat -lant | grep 8080
(on Windows, can try the resource monitor you can find in task manager)
If you see 0.0.0.0:8080, then you are listening on all interfaces. If you don’t see that port and «LISTENING» at all, then your tomcat is not listening.
If this is not working, check the server log (eg. tomcathome/logs/catalina.out) or tomcathome/conf/server.xml to see if the port is different. I find it common that the catalina.out has the answer (eg. maybe you ran it as a non-root user and port 80, which being <1024 isn’t allowed in Linux/Unix)
Test it locally.
$ telnet localhost 8080
$ telnet <your ip here, not localhost or 127.0.0.1> 8080
(On Windows, I’m not sure what to try instead of telnet… you want something that will ignore redirections, sessions, authentication, etc. and just give you a raw simple answer; maybe use cygwin and the «curl -v» command)
(to exit telnet, hit ctrl+] and then type «quit» and hit enter)
Test it remotely:
$ telnet <your ip here, not localhost or 127.0.0.1> 8080
If there are differences between the local test and remote test, examime the firewalls on all machines in between, including the server and client. (Linux clients generally don’t block anything outgoing, but Windows 7 might)
And last but not least, run tcpdump:
$ sudo tcpdump not port 22
(tcpdump is also available for windows)
Then in another window, start the tomcat server, and then try to connect with a client to see what happens. (Others prefer wireshark or other tools; I’m probably the only one using the raw low level one)
And look for the port numbers in tcpdump’s output. Try adding more conditions to exclude things you don’t care about (eg. broadcasts, netbios, etc…. whatever else is running on the server; I excluded 22 so if you ssh in, you don’t see your own ssh traffic spamming you) Some stupid application servers (eg. old Jboss versions) do terribly stupid things, making terrible assumptions, and try connecting on ports that aren’t open (for mxbeans or whatever they are called) before they can even start listening, and sometimes fail because of it.