How to put a time restriction on a method in java?

I have a specific requirement where in I am calling a method and I want to get the response within a specific duration.
For example, I am trying to fetch the contents of a web-page.

If within 3 seconds, I get the response, its good, otherwise, I want to give a message to the user that internet is too slow.

Now, how do I do this?

You could make use of the ExecutorService and its timeout facilities. The idea is to execute the method you want to call in a different thread, and let the ExecutorService cancel it after a specific time. Here is a simple example, using two fixed threads. You’d have to adapt this to your needs.

Make a class MyTask implements Callable

package testapp;
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;

class MyTask implements Callable {

private String name;
private long sleepTime;

public MyTask(String name, long sleepTime) { = name;
this.sleepTime = sleepTime;

public Void call() throws Exception {
System.out.println("Starting task " + name);
System.out.println("Finished task " + name);
return null;

Use this as is done here

public class ExecutorServiceTest {

public static void main(String[] args) throws InterruptedException {
ExecutorService service = Executors.newFixedThreadPool(2);
Collection<Callable> tasks = new ArrayList<Callable>();
tasks.add(new MyTask("Task1", 10000));
tasks.add(new MyTask("Task2", 2000));
System.out.println(new java.util.Date());
List<Future> taskFutures = service.invokeAll(tasks, 2L, TimeUnit.SECONDS);
for (Future future : taskFutures) {
System.out.println("Done: " + future.isDone());
System.out.println("Cancelled: " + future.isCancelled());
System.out.println(new java.util.Date());



Best Practices while writing Java code

Usually many of us write the java code in a try-catch block as follows

// some code here
catch(Exception e)
// log exception here

Better way to do it is

// some code here
catch(Exception e)
// log exception here
catch(Throwable ex)
// One must add throwable clause always
// because in case of some error also, you can
// log it and see, what error has occured.

If you do not add Throwable clause, and in production, some error occurs, Then nothing will be logged in your logs, you may end up breaking your head, why the hell it is not working.

Make it a habit to use try-catch-Throwable in place of try-catch-Exception

How to use logger in your Java application

How to log Messages in your application?

Java’s logging facility has two parts: a configuration file, and an API for using logging services. It is suitable for simple and moderate logging needs. Log entries can be sent to the following destinations, as either simple text or as XML:
· The console
· A file
· A stream
· Memory
· TCP socket on a remote host

The LEVEL class defines seven levels of logging enlightenment :
FINEST, FINER, FINE, CONFIG, INFO, WARNING, SEVERE .ALL and OFF are defined values as well

The levels in code may be modified as required :
· Upon startup, by using CONFIG to log configuration parameters
· During normal operation, by using INFO to log high-level “heartbeat” information
· When bugs or critical conditions occur, by using SEVERE.
· Debugging information might default to FINE, with FINER and FINEST used occasionally, according to user need.

There is flexibility in how logging levels can be changed at runtime, without the need for a restart:
· By simply changing the configuration file and calling LogManager.readConfiguration.
· By changing the level in the body of code , using the logging API ;
For example, one might automatically increase the logging level in response to unexpected events

The logging levels are in descending order SEVERE, WARNING, INFO, CONFIG, FINE, FINER and FINEST. If we specify log level as

INFO then all the log messages which are equal to INFO and greater (WARNING, SEVERE) levels will be logged.

Levels are attached to the following items:
· An originating logging request (from a single line of code)
· A Logger (usually attached to the package containing the above line of code)
· A Handler (attached to an application)

Here is an example of a logging configuration file :

Properties file which configures the operation of the JDK

logging facility. # The system will look for this config file, first using

a System property specified at startup:

>java -Djava.util.logging.config.file=myLoggingConfigFilePath

If this property is not specified, then the config file is retrieved

from its default location at:


Global logging properties.


The set of handlers to be loaded upon startup.

Comma-separated list of class names.

(? LogManager docs say no comma here, but JDK example has comma.)

handlers=java.util.logging.FileHandler, java.util.logging.ConsoleHandler

Default global logging level.

Loggers and Handlers may override this level




Loggers are usually attached to packages.

Here, the level for each package is specified.

The global level is used by default, so levels

specified here simply act as an override.




— ConsoleHandler —

Override of global logging level


— FileHandler —

Override of global logging level


Naming style for the output file:

(The output file is placed in the directory

defined by the “user.home” System property.)


Limiting size of output file in bytes:


Number of output files to cycle through, by appending an

integer to the base file name:


Style of output (Simple or XML):


Here is an example of using the logging API :

import java.util.logging.*;
* Demonstrate Java's logging facilities, in conjunction
* with a logging config file.
public final class SimpleLogger {

  public static void main(String argv[]) {
    SimpleLogger thing = new SimpleLogger();
   public void doSomething() {
   //Log messages, one for each level
   //The actual logging output depends on the configured
    //level for this package. Calls to "inapplicable"
    //messages are inexpensive.
     fLogger.finest("this is finest");
    fLogger.finer("this is finer");
    fLogger.fine("this is fine");
    fLogger.config("this is config");"this is info");
    fLogger.warning("this is a warning");
    fLogger.severe("this is severe");

    //In the above style, the name of the class and
    //method which has generated a message is placed
    //in the output on a best-efforts basis only.
    //To ensure that this information is always
    //included, use the following "precise log"
    //style instead :
    fLogger.logp(Level.INFO, this.getClass().toString(), "doSomething", "blah");

    //For the very common task of logging exceptions, there is a
    //method which takes a Throwable :
    Throwable ex = new IllegalArgumentException("Some exception text");
    fLogger.log(Level.SEVERE, "Some message", ex);

    //There are convenience methods for exiting and
    //entering a method, which are at Level.FINER :
    fLogger.exiting(this.getClass().toString(), "doSomething");

    //Display user.home directory, if desired.
    //(This is the directory where the log files are generated.)
    //System.out.println("user.home dir: " + System.getProperty("user.home") );

  // PRIVATE //

  //This logger will inherit the config of its parent, and add
  //any further config as an override. A simple style is to use
  //all config of the parent except, perhaps, for logging level.

  //This style uses a hard-coded literal and should likely be avoided:
  //private static final Logger fLogger = Logger.getLogger("");

  //This style has no hard-coded literals, but forces the logger
  //to be non-static.
  //private final Logger fLogger=Logger.getLogger(this.getClass().getPackage().getName());

  //This style uses a static field, but hard-codes a class literal.
  //This is probably acceptable.
  private static final Logger fLogger = Logger.getLogger(SimpleLogger.class.getPackage().getName());