I need to use logback in a client server program, for each request that comes to server, it creates a new service which will run in a separate thread. I need to log actions that happen during service excecution. But i dont want to generate separate logger object for each service thread. I know that one solution would be to set the logger object as static. So it wont be instanciated every time but is there any standard solution for this kind of problem. bellow are some code snippets from my source code:
The server class which creates a separate servcie thread for each request:
1: a logger specific for server class.
2: for each incomming request that comes to server we generate a new thread (new instance of service class),but the question is that we dont want to have a logger instances for each service instance (i guess it is a bad practice!)
and here is the service class :
*:logger is defined static so it wont be instanciated for each service class instance:
i know that one solution would be to set the logger object as static so it wont be instanciated every time but is there any standard solution for this kind of problem.
This is what I do in my application. It works great.
Many of my classes have this as the first line:
public class SomeClass {
private static final Logger LOG = LoggerFactory.getLogger(SomeClass.class);
// the rest of the class
}
Also, if you want the log messages to reflect which overall request is the one doing the logging, you should use MDC:
One of the design goals of logback is to audit and debug complex distributed applications. Most real-world distributed systems need to deal with multiple clients simultaneously. In a typical multithreaded implementation of such a system, different threads will handle different clients. A possible but slightly discouraged approach to differentiate the logging output of one client from another consists of instantiating a new and separate logger for each client. This technique promotes the proliferation of loggers and may increase their management overhead.
Read the entire link, it does a better job of explaining MDC than I ever could.
Related
There are number of method to create logger instance.
one instance of Logger per class
one instance of Logger per thread
one instance of Logger per application
Can any one suggest performance on each method?
Currently i am using one logger object per application so Is this down multithreaded application performance?.
A good tracking resource is Jamon, I guess you know it. Inside an EE application there is a simple way to "hook" it to every method call, in order to trace all method's execution time. In this way, you could analyze the impact of your "added" log calls
Back to your question, I don't think there should be performance issues, as the log output is anyway serialized and instantiating per method, classs or even application is just a matter of used memory
Please note: Although this question mentions Java, I think it's an OOP/concurrency problem at heart and can probably be answered by anyone with significant programming experience.
So I'm building a ConfigurationLoader that will read Configuration POJO from a remote service and make it available via an API. A few things:
As soon as the ConfigurationLoader is asked for the Configuration the first time, a background thread (worker) will ping the remote service every, say, 30 seconds, for updates and then apply those updates to the Configuration instance; and
If the Configuration is modified, the background worker will be notified of the change and will push the "new" Configuration to the remote service;
Both the ConfigurationLoader and the Configuration must be thread-safe
So when I think "thread safety" the first thing I think of is immutability, which leads me towards excellent projects like Immutables. The problem is that Configuration can't be immutable because we need to be able to change it on the client-side and then let the loader ripple those changes back to the server.
My next thought was to try and make both ConfigurationLoader and Configuration singletons, but the problem is there is that the ConfigurationLoader takes a lot of arguments to instantiate it, and as this excellent answer points out, a singleton that takes arguments in construction is not a true singleton.
// Groovy pseudo-code
class Configuration {
// Immutable? Singleton? Other?
}
class ConfigurationLoader {
// private fields
Configuration configuration
ConfigurationLoader(int fizz, boolean buzz, Foo foo, List<Bar> bars) {
super()
this.fizz = fizz
this.buzz = buzz;
// etc.
}
Configuration loadConfiguration() {
if(configuration == null) {
// Create background worker that will constantly update
// 'configuration'
}
}
}
What are my options here? How do I create both the loader and the config to be thread-safe, where the config is changeable by the client-side (on-demand) or asynchronously by a background worker thread?
The problem is that Configuration can't be immutable because we need to be able to change it
It can still be immutable, you just create a new one for every change ("copy-on-write").
What are my options here?
First thing you'll have to think about: How do you want to react to configuration changes in concurrently running tasks? Basically, you have three options:
Ignore configuration change until the task is done
I.e. some directory your codes writes files to - finish writing the current file to the current target dir, put new files in the new dir. Writing some bytes into /new/path/somefile won't be a good idea if you never created that file. Your best option for this is probably an immutable Configuration object that you store in a field of your task instance (i.e. at task creation - in that case you can also make that field final for clarity). This usually works best if your code is designed as a collection of isolated small tasks.
Pros: Config never changes within a single task, so this is simple to get tread-safe and easy to test.
Cons: Config updates never make it to already running tasks.
Make your tasks check for config changes
I.e. your task regularly sends some data to an email address. Have a central storage for your config (like in your pseudo-code) and re-fetch it in some interval (i.e. between collecting data and sending the mail) from your task code. This usually works best for long-running/permanent tasks.
Pros: Config can change during a task run, but still somewhat simple to get safe - just make sure you have some memory barrier in place for reading the config (make your private configuration field volatile, use an AtomicReference, guard it with a lock, whatever).
Cons: Task code will be harder to test than first option. Config values may still be outdated between checks.
Signal config changes to your tasks
Basically option two, but the other way around. Whenever config changes, interrupt your tasks, handle the interrupt as a "config needs updating" message, continue/restart with new config.
Pros: Config values are never outdated.
Cons: This is the hardest to get right. Some might even argue that you cannot get this right, because interruption should only be used for task abortion. There is only very minor benefits (if at all) over the second option if you place your task's update checks at the right spots. Don't do this if you don't have a good reason to.
You need a singleton to pull this off, but your singleton isn't the immutable thing. Its the threadsafe thing. Make your singleton (Configuration) contain a simple Properties object or something and protect access to this with synchronization. Your Configuration Loader somehow knows of this Configuration singleton and functions to set, under synchronization, new instances of the Properties object when it detects change.
I'm pretty sure Apache Commons Configuration does something like this.
I wrote custom java class, a special http connector in the flow with request-response mule-http connector.
But if there are too many requests calls this flow, an IllegalStateException occured.
As far as i know the data or variables from one thread copies to another thread and I get an IllegalState...
How can I synchronize data in my connector? May I forget to implement some interfaces?
public class MyHTTPConnector {
...
}
I synchronize all methods in my class and solve the problem. Thanks everyone for assistance.
I have a requirement in my java web application where I need to send email alerts for certain conditions. For this I have used javax mail api and sending email works just fine. But the problem is the programs executions waits until the methods for sending the email are executed. As there are hundreds of email to be sent at various points ... this reduces the performance significantly.
I am using spring and have also used spring aop. Can anyone suggest me how can I separate my business logic and sending email functionality. It should be like -
Sending emails is my advice which gets executed when xyz method is called - So main execution should not wait for advice to finish its execution rather it should return back and execute further business logic thus email sending executed separately.
Here creating new threads seems obvious choice. But I think there could be some better way, is there? Thanks.
You can make the mail sending method #Async. This way Spring will execute this in a seperate thread. Read this blog post about it: Creating Asynchronous Methods
What you describe is asynchronous execution and natural way to do async execution is Java is to use threads.
You can introduce some Executor, e.g., Executors.newFixedThreadPool(), and use it to offload mailing task into separate threads.
Aspect itself is a unsuitable place for this, since this would introduce state into aspect, for example, you may want to check if mail task was successful by using returned Future:
class Mailer {
private final ExecutorService executor = Executors.newFixedThreadPool(maxMailingThreads);
//...
public void doMail(MailTask anEmail) {
Future<MailTaskResult> future = executor.submit(new MailTask(anEmail));
future.get().isSuccessful(); // handle success or failure somehow
}
Better move this logic into separate class and call it from aspect somehow.
Treat the email sending functionality like an IO device. Make it a plugin to your business logic. Do not allow any knowledge of the fact that you're even talking to the email code into your business logic. Make the email logic depend on the business logic. Never the other way around.
Here's a very good talk about this kind of architecture:
https://vimeo.com/97530863
Here's a series debating it:
https://www.youtube.com/watch?v=z9quxZsLcfo
Here's a ruby master demonstrating it with real code. We miss him.
https://www.youtube.com/watch?v=tg5RFeSfBM4
If your business rules are interesting enough to be worth respecting than this is the way to make them the masters of your application. Express them only using java. Don't accept any help. No spring, no weird annotations, just business rules. Push all that "help" out to the mail code.
Do this and your app will scale well. I think this is the best way to put it:
That's from a hexagonal architecture post. But the idea of giving your business rules a safe place to live removed from implementation detail shows up in many architectures. This answer rounds them up nicely.
Use a localhost MTA (like OpenSMTPD) and then relay to your real SMTP server, like Amazon SES ("Satellite" mode). It won't block.
I did a test, and sent 1000 emails in 2.8 seconds this way
It's simpler than doing async in java, and is useful across multiple applications.
As for separating logic, raise a Spring Application Event when needed, and make another class to listen to it, and send your email from there. Or consider something like Guava's EventBus
Consider creating a separate thread to send emails within your application. This will allow parallel execution(application+email sending).
If you would want another approach you can create a separate back end application that only sends emails. Although you will need to submit the email messages to the application. An asynchronous way to do this is to send a JMS message to the email application.
I have a web application where multiple servlets use a certain amount of identical logic for pre-initialization (setting up logging, session tracking, etc.). What I did was to introduce an intermediary level between javax.servlet.http.HttpServlet and my concrete servlet class:
public abstract class AbstractHttpServlet extends HttpServlet {
// ... some common things ...
}
and then:
public class MyServlet extends AbstractHttpServlet {
// ... specialized logic ...
}
One of the things I do in AbstractHttpServlet's default (and only) constructor is to set a few private member variables. In this case it is a UUID, which serves as a session identifier:
public abstract class AbstractHttpServlet extends HttpServlet {
private UUID sessionUuid;
public AbstractHttpServlet() {
super();
this.sessionUuid = UUID.randomUUID();
// ... there's more, but snipped for brevity ...
}
protected UUID getSessionUuid() {
return this.sessionUuid;
}
}
I then use getSessionUuid() in MyServlet to provide for session tracking within the request. This is very useful e.g. in logging, to be able to sift through a large log file and get all entries relating to a single HTTP request. In principle the session identifier could be anything; I just picked using a UUID because it is easy to generate a random one and there's no need to worry about collisions between different servers, seed issues, searching through the log file turning up a match as a portion of a longer string, etc etc.
I don't see any reason why multiple executions should get the same value in the sessionUuid member variable, but in practice, it appears that they do. It's as if the instance of the class is being reused for multiple requests even over a long period of time (seemingly until the server process is restarted).
In my case, class instantiation overhead is minor compared to the useful work done by the class, so ideally I'd like Tomcat to always create new class instances for each request and thus force it to execute the constructor separately each time. Is it possible to perhaps annotate the class to ensure that it is instantiated per request? Answers that don't require server configuration changes are much preferred.
Failing that, is there a way (other than doing so separately in each do*() method such as doGet(), doPost(), etc.) to ensure that some sort of initialization is done per HTTP request which results in execution of a particular servlet?
It's as if the instance of the class is being reused for multiple requests even over a long period of time (seemingly until the server process is restarted).
Yes, that's exactly what will be happening, and what you should expect.
A servlet isn't meant to be a session - it's just meant to be the handler.
If you want to do "something" on each request, no matter what the method, you can override the service method, take whatever action, and then call super.service(). However, you shouldn't change the state of the servlet itself - bear in mind that multiple requests may execute in the same servlet at the same time.
Basically, what you're asking for goes against the design of servlets - you should work with the design rather than against it. You could modify the request itself (using setAttribute) to store some information related to just this request - but I'd probably do that at a higher level than HTTP anyway. (I'd try to make the servlet itself very small, just delegating to non-servlet-aware classes as far as possible, which makes them easier to test.)
This code is not threadsafe. The servlet container will generally create one instance of the servlet and all requests will use it.This means that the sessionUUID will be shared by all requests and will be continually overwritten.
If you need to keep this value on a per request basis, consider using a ThreadLocal object and putting the UUID in there.
It's as if the instance of the class is being reused for multiple requests even over a long period of time.
There is always one instance of a Servlet class at any given point in time per JVM. Hence instance variables are not thread safe in Servlet. Each request for the Servlet will be processed by a thread. Local variables declared inside the service(),doPost() and doGet() will be thread safe .
Hence you can move your logic to some other class , instantiate it inside the service methods and use it in thread safe fashion.You can even use ThreadLocal objects.
There is a provision to implement the SingleThreadModel ,it is deprecated, it is not only bad but ridiculous to do so.
Ensures that servlets handle only one request at a time. This interface has no methods.
If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet.
Better to implement a ServletRequestListener and put the logic there.