We Keep Coding

Java: Is it good practice to do static HTTP Requests?

I just had a discussion with a colleague who asked me why i would do a static Http request like this:
HttpClient.doGet(HashMap<String,String> Parameters);
instead of invoking an object of the class via default constructor and use a nonstatic method like this:
new HttpClient().doGet(HashMap<String,String> Parameters)
If assuming that the implementation of the method doGet only uses the parameters of the function without any member variables, would the static implementation be problematic in any way, e.g. thread safety?

It depends on what you mean by problematic, but going off just your given example, the answer is no, the static method call is not problematic, and is arguably better, since no object needs to be instantiated.
You mentioned thread safety, so I will touch on that. You only need to be concered with thread safety if there is "mutable shared state" involved. Mutable being the key-word here. For example, if multiple threads were sharing the same instance of HttpClient, and that HttpClient was keeping track of some state by mutating one or more of its member variables, then that definitely has the potential to be problematic.

... but also, every HTTP request has to go out on a network, to a physical computer someplace else, then to return, "at least many milli- seconds later." So, there's really no point in "multi-threading" that chore. A single thread can be given the responsibility for sending out parallel I/O-requests to the remote hosts, receiving requests from the rest of your code by means of some thread-safe queue and returning the responses in like manner on another queue (or, queues).
It is wasteful to associate "a thread" with "a request." A very small pool of workers can be consuming the responses that come off of that reply-queue.
(And of course, there are plenty of existing Java open-source frameworks that implement all of this very-familiar plumbing for you.)

if multiple requests are handled by a server to run a single servlet then where we need to take care of synchronization?

If multiple requests are handled by a server to run a single servlet then where we need to take care of synchronization?
I have got the answer from How does a single servlet handle multiple requests from client side how multiple requests are handled. But then again there is a question that why we need synchronization if all requests are handled separately?
Can you give some real life example how a shared state works and how a servlet can be dependent? I am not much interested in code but looking for explanation with example of any portal application? Like if there is any login page how it is accessed by n number of users concurrently.
If more than one request is handled by the server.. like what I read is server make a thread pool of n threads to serve the requests and I guess each thread will have their own set of parameters to maintain the session... so is there any chance that two or more threads (means two or more requests) can collide with each other?

Synchronization is required when multiple threads are modifying a shared resources.
So, when all your servlets are independent of each other, you don't worry about the fact that they run in parallel.
But, if they work on "shared state" somehow (for example by reading/writing values into some sort of centralized data store); then you have to make sure that things don't go wrong. Of course: the layer/form how to provide the necessary synchronization to your application depends on your exact setup.
Yes, my answer is pretty generic; but so is your question.

Synchronization in Java will only be needed if shared object is mutable. if your shared object is either read-only or immutable object, then you don't need synchronization, despite running multiple threads. Same is true with what threads are doing with an object if all the threads are only reading value then you don't require synchronization in Java.
Read more

Basically if your servlet application is multi-threaded, then data associated with servlet will not be thread safe. The common example given in many text books are things like a hit counter, stored as a private variable:
e.g
public class YourServlet implements Servlet {
private int counter;
public void service(ServletRequest req, ServletResponse, res) {
//this is not thread safe
counter ++;
}
}
This is because the service method and Servlet is operated on by multiple thread incoming as HTTP requests. The unary increment operator has to firstly read the current value, add one and the write the value back. Another thread doing the same operation concurrently, may increment the value after the first thread has read the value, but before it is written back, thus resulting in a lost write.
So in this case you should use synchronisation, or even better, the AtomicInteger class included as part of Java Concurrency from 1.5 onwards.

Creating thread for background task servlet

The scenario of my problem is:
In my servlet I get a large amount of data from somewhere (not relevant). I have to iterate over all this data and put it in an array, convert it to a JSON object and send it to the client side for viewing. If I do this in a single response it takes a very long time to display the results. Hence, I need to do multithreading.
The created thread needs to keep on adding data to the list while the main thread whenever it gets a request (requests for data keep on coming periodically) sends the present available list.
For instance on first request the response sent is : 1 2 3
Second request : 4 5 6 and so on.
Now I come to actual problem : I don't know how to do multithreading in a servlet. I have looked through numerous resources and examples but it only has confused me further. Some examples have created threads right in doGet which I think is very wrong, some have created them in the init() method but I dont know how can I pass parameters and get results from the thread if it is declared in the init method (It cannot be a global variable). Then there are examples of servletContextListener but I havent found anything useful or that makes sense.
Can anyone please guide to me a reliable source or just give me some sort of pseudo code to get a solution to my problem. It would be extremely helpful if the answers are in context with the aforementioned scenario.
Thanks

The created thread needs to keep on adding data to the list while the
main thread whenever it gets a request (requests for data keep on
coming periodically) sends the present available list.
If I got you correct, you like to get some data as background service and make them ready for clients once they request them(sounds like harvesting data).
Well, creating thread in web-apps, or generally stuffs come with managed environment is different, creating a thread implicitly would cause of memory leak.
One good solution would having a ThreadPool(either by container context/ndi or create it manually).
AND it MUST be created in a manageable manner, where you would control it by environment related events.
ContextListener is your friend, having a context listener class, like this.
public class dear_daemon implements ServletContextListener,Runnable{
ExecutorService the_pool;
Thread the_evil;
/*following get invoked once the context is called*/
public void contextInitialized(ServletContextEvent sce){
/*initialize the thread-pool, and run evil thread*/}
/*following get invoked once the context is destroying*/
public void contextDestroyed(ServletContextEvent sce){eviling=false;
/*stop evil(this) thread(first), then destroy thread pool*/
}
volatile boolean eviling=true;
public void run(){
while(eviling){
/*run Runnable instance which do data fetching using thread-pool*/
}
}
}
And register the listener in web.xml
<listener>
<listener-class>dudes.dear_daemon</listener-class>
</listener>
Having a class(runnable) which do the data fetching, and invoke it by evil thread, each instance using one thread.
The ContextLisstener helps you correctly shutdown and manage init and hult events by container, using the same thing with servlet init is possible, but make sure you do the same thing about hulting with destroy method of servlet.
If you like to do thread-thing about it, make sure you are doing things thread-safe since you have one thing to store data(a list).
If any synchronization is needed(for example ordering the fetched data), make sure you are doing it right, or you will face with deadlocks, or low-performance code.
If any(probably) IO action is needed for getting data, note java IO is blocking, so set appreciated read and connection timeouts, or switch to NIO if you can handle complex NIO stuffs.
If applying these changes make the environment complex, and you like to do alternative solutions, you may simply extract the data fetching from web-profile and run it as a external daemon-service or applciation, where the applciation will pass the fetched data to the server context using calling one of your CGI/Servlet.

Swing application using threads based on MVC

My application has some Threads that are initiated in Main Class.
And I want to use MVC in this Swing Application.
The Main class waits a socket connection from some client, then when the client is connected I create a telnet object from a Telnet class that I create. And this class has all the shared resources that the threads will use.
After this I start my threads, passing the telnet object as a parameter, so it will be used to syncrhonize the threads.
There are five threads in my application: Client, Management, Server, Node and Agent.
Each one has a specific function.
So this is my scenario.
I want to use MVC in my application to organize these threads more properly, and make the application more easy to maintain.
I've already used MVC in Swing application, but without threads.

Perhaps it's me, but your question still seems quite broad to me, and so I can only offer broad suggestions.
Key in my mind will be how will objects communicate with each other, and I think that this is more important to me than how "Threads" communicate.
Best I think is to use an observer pattern.
If your Threads are created using a SwingWorker, then you have two main ways to communicate back to your Swing application:
You can use the publish/process method pair, where you pass an object into a publish method call, and then make Swing calls, perhaps to change your model's state via the process method. I don't like this approach as well, since coupling is increased, as the SwingWorker must know about the structure and behavior of the view or control code that it calls inside of the process method.
Or you can use the SwingWorker's innate SwingPropertyChangeSupport abilities to allow listeners (here the controller) to be notified of changes in the state of the worker. Then the controller can extract information that has changed and pass it to the model. I tend to favor this approach since for me, it is much easier to loosen coupling.

ThreadLocals hard to use

I'm using ThreadLocal variables (through Clojure's vars, but the following is the same for plain ThreadLocals in Java) and very often run into the issue that I can't be sure that a certain code path will be taken on the same thread or on another thread. For code under my control this is obviously not too big a problem, but for polymorphic third party code there's sometimes not even a way to statically determine whether it's safe to assume single threaded execution.
I tend to think this is a inherent issue with ThreadLocals, but I'd like to hear some advise on how to use them in a safe way.

Then don't use ThreadLocals! They are specifically for when you want a variable that's associated with a Thread, as if there were a Map<Thread,T>.

The typical use case (as far as I know) for a ThreadLocal is in a web application framework. An HTTP filter obtains a database connection on an incoming request, and stores the connection in a static ThreadLocal. All subsequent controllers needing the connection can easily obtain it from the framework using a static call. When the response is returned, the same filter releases the connection again.