• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Threads stuck in java.net.SocketInputStream.socketRead0

 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



What does java.net.SocketInputStream.socketRead0() API do? Why is it showing up frequently in several thread dumps? Why is it reported in thread dump analysis tools like fastThread.io? Is it something that I need to be concerned about? What are the potential solutions to this problem? Let’s find answers to these questions.

What does SocketInputStream.socketRead0() API do?
It’s always easy to remember new concepts through real life analogies. Say suppose you are calling your wife or girlfriend on the phone. Once call gets connected, if she is in happy/good mood immediately you will get response “Hello Honey (or darling or sweetie), How are you?”. :-). If your call got connected when she is in middle of doing some work (say she is in her office, picking up kids, Gym…) there might be delay in her response to say “Hello Honey (or darling or sweetie) ….”. Suppose your call got connected when she is in angry/bad mood then response can be unpredictable. God only knows. You might get response after several seconds/minutes (or even call can get hanged up :-). So, the time you are waiting since the moment call got connected until the moment you hang-up the call is basically socketRead0() API. (Thanks to Douglas Spath from IBM for giving this beautiful example to explain this SocketRead0() API.)

Your application might be interfacing with multiple remote applications through various protocol likes: SOAP, REST, HTTP, HTTPS, JDBC, RMI… all connections goes through JDK java.net layer to perform lower TCP-IP/Socket operations. In this layer, SocketInputStream.socketRead0() API is used to read and receive the data the remote application. Some remote applications may respond immediately, some might take time to respond, some application may not respond at all. Until your application reads the response data completely, your application thread will be stuck in this java.net.SocketInputStream.socketRead0() API.

Sample Thread dump stacktrace
Below are some sample stacktrace that shows the threads that are stuck in ‘SocketInputStream.socketRead0’ API. You can notice irrespective of the protocol threads to get stuck on SocketInputStream.socketRead0() API.


   
    Fig: RMI thread stuck in SocketInputStream.socketRead0() API



    Fig: Oracle Database connection stuck in SocketInputStream.socketRead0() API



   Fig: RabbitMQ stuck in SocketInputStream.socketRead0() API



 Fig: IBM DB2 statement execution stuck in SocketInputStream.socketRead0() API

Solutions

If you a thread gets stuck in SocketInputStream.socketRead0 API and doesn’t recover from it for a longer period, then customer whoever originated the transaction will not see any response in his screen. It can puzzle, confuse the user. If multiple threads get stuck in SocketInputStream.socketRead0 API and doesn’t recover for a longer period it can pose serious availability concerns to your application.

Here with we are outlining few potential solutions to address this problem:
Please have a look into it.


 
CAUTION! Do not touch the blades on your neck propeller while they are active. Tiny ad:
Enterprise-grade Excel API for Java
https://products.aspose.com/cells/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!