This link suggests to create an abstract base class that can read the job data map information for Quartz.net and each of the jobs will derive from this base class.
http://quartznet.sourceforge.net/faq.html#howtochainjobs
Can someone provide me a sample of this base class because I am not sure how to retrieve the job details in the base class and then call the Execute method on the derived class?
Pratik
Creating an abstract base class is just a suggestion made by the Quartz.NET documentation, and is not a requirement for implementing job chaining. Basically they are suggesting that if you want to chain jobs: "AJob" -> "BJob" -> "CJob", you would do something along the lines of this:
Create abstract class "ChainBaseJob".
Make your job class (which both AJob and BJob are types of) inherit from ChainBaseJob.
ChainBaseJob would contain some sort of method like:
string GetNextJobInChain()
...which would return the name of the job (meaning the Quartz job name). There's a variety of ways to do use this, but I guess the documentation is suggesting that your TriggerListener checks to see (during the job completed method) if a completed job (let's say "AJob") inherits from ChainBaseJob. If it does, it will cast it and call GetNextJobInChain, and use the name returned by the method to call the scheduler to execute it upon completion of AJob. If everything is implemented correctly, the TriggerListener will know to execute BJob, after AJob completes.
Good luck.
Related
I would like to sort things such as sending notification emails out into the far-backend and write a couple of job classes. Like:
import JobBase from "some library...";
class SendEMails extends JobBase {
// ...
}
Now, I did see a couple of Redis-backed job/task queues for Node, but appearently, they all just seem to operate on a single queue in Redis...which is kind of surprising, knowing that ES6 is around since a while now.
What would be a good method of defining job classes and running them when a job is queued - and having that organized in classes?
I really don't want to re-invent the wheel and write my own implementation... :)
I'm running a profiler against a running Java service (Spring Boot framework), containing multiple Groovy files all with the #CompileStatic annotation.
Now one of the most time consuming methods is an internal Groovy method (getSAMMethodImpl()). I've been unsuccessful tracking down what this method is actually doing under the covers.
What exactly does this method do, and is there any way to prevent it from being called?
This method gets executed when a CachedClass for a class with a single abstract method (aka SAM) is created. Cached classes are Groovy mechanism to deal with a reflection in a more effective way - instead of always retrospecting classes from the beginning at the runtime it remembers e.g. modifications applied with metaprogramming (adding new methods to classes for instance), so it gets all class information very quickly. Of course it comes with some overhead.
For instance, when the meta class registry is initialized (once), it registers about 1180 methods. About 190 of them cause CachedSAMClass.getSAMMethodImpl(Class<?> c) to be executed. It happens, because ClassInfo.isSAM(Class<?> c) which checks if given class is a single abstract method class calls this method. And if you take a look at ClassInfo.createCachedClass(Class klazz, ClassInfo classInfo) you will see that this isSAM() method gets called always as a last check.
In most cases creating a registry of cached classes shouldn't be a problem - it happens one time for each class. Most of them get registered when you simply access metaClass property of any class. Or when you create a first closure. When it comes to performance, many different factors matter. For instance, Spring Boot uses hot swapping to reload classes at the runtime. In this case Groovy meta class registry gets recreated and all cached classes have to be recreated as well. The same thing may happen when you run a Spring Boot application with spring-boot-devtools dependency added - it uses additional class loader called RestartClassLoader which requires additional meta class registry to be initialized. Actually the number of class loaders you have, that number of times meta class registry will be initialized (once for each class loader). This RestartClassLoader also causes recreating cached classes when it restarts.
And last but not least - if you want to measure performance correctly, try doing it on a production server instead of a local dev environment. If you can attach a debugger to the running process on a server and put a breakpoint in CachedSAMClass.getSAMMethodImpl(Class<?> c) at line 169, you can see how many times and for what classes this method gets executed. If it happens that it gets executed multiple times for the same class, it may suggest that your application is restarting class loader and Groovy has to rebuild meta class registry. It shouldn't happen - production application once started should not make any changes to class loader without a purpose. It is acceptable on a local dev - devtools and hot swapping will force meta class registry to be recreated any time class loader gets refreshed.
Context
This is a unit test scenario.
The methods of the test target class can be called concurrently from different threads, so instead of guarding the logger implementation instance itself with locks, I've chosen to have a thread bound singleton loggers. The methods under test always creating their thread bound loggers via service locator pattern (please do no hijack the question about is this an antipattern or not).
Ninject is programmed as follows in the Arrange part of the test:
kernel.Bind<ILogger>().To<MyLogger>().InThreadScope();
Question
During the Act part of the test, one or more thread is created by the instance under test (inside).
In the Assert part of the test, I would like to access to the one or more loggers what were created an used by the threads in the class under test, and examine that loggers in the purpose of assertion.
How can I accomplish this task? (access the loggers what was created)
Ninject does not offer a specific API for this, however, you can make use of "OnActivation".
Either add it to your existing binding, or use Rebind in the unit test, as follows:
kernel.Rebind<ILogger>().To<MyLogger>().OnActivation(createdInstance => ...do something...);
Replace the "...do something..." with an Action<ILogger> that adds the instance to a (concurrency-safe?) list or similar.
Also see Intercept creation of instances in Ninject for further information.
In my play application I have several Jobs and I have a singleton class.
What I would like to do is for each Job to store data in the singleton class and I would like to be able to retrieve from this singleton class the data that corresponds to the current Job via yet another class.
In other words I would like to have something like this:
-Job 1 stores "Job1Data" in the singleton class
-Job 2 stores "Job2Data" in the singleton class
-Another class asks the singleton class data for the currently executing job (in the current thread I guess) and use it
To perform this I assumed each Job is run on a different thread. Then what I did is that data from each Job stored in the singleton class is stored in a Map that maps the current thread id with the data.
However I'm not sure this is the way I should do it because it may not be thread safe (although Hashtable is said to be thread-safe) and maybe another thread is created each time the Job is executed which would make my Map grow a lot and never clear it-self.
I thought of another way to do what I want. Maybe I could use the ThreadLocal class in my singleton to be sure it's thread-safe and that I store thread-specific data. However I don't know if it will work well if another thread is used each time a Job is executing. Furthermore, I read somewhere that ThreadLocal creates memory leaks if the data is not remove, and the problem is that I don't know when I can remove the data.
So, would anybody have a solution for my issue ? I would like to be sure data I would like to store during Job execution is stored in a global class and can be accessed by another class (with an access to the data of the correct Job, thus the correct thread I guess).
Thank you for your help
Why is the struts action class is singleton ?
Actually I am getting point that it is multithreaded. but at time when thousand of request hitting same action, and we put synchronized for preventing threading issue, then it not give good performance bcoz thread going in wait state and it take time to proced.
Is that any way to remove singleton from action class ?
for more info Please visit : http://rameshsengani.in
You are asking about why the Action class is a singleton but I think you also have some issues understanding thread safety so I will try to explain both.
First of all, a Struts Action class is not implemented as a singleton, the framework just uses one instance of it. But because only one instance is used to process all incoming requests, care must be taken not to do something with in the Action class that is not thread safe. But the thing is: by default, Struts Action classes are not thread safe.
Thread safety means that a piece of code or object can be safely used in a multi-threaded environment. An Action class can be safely used in a multi-threaded environment and you can have it used in a thousand threads at the same time with no issues... that is if you implement it correctly.
From the Action class JavaDoc:
Actions must be programmed in a thread-safe manner, because the controller will share the same instance for multiple simultaneous requests. This means you should design with the following items in mind:
Instance and static variables MUST NOT be used to store information related to the state of a particular request. They MAY be used to share global resources across requests for the same action.
Access to other resources (JavaBeans, session variables, etc.) MUST be synchronized if those resources require protection. (Generally, however, resource classes should be designed to provide their own protection where necessary.
You use the Struts Action by deriving it and creating your own. When you do that, you have to take care to respect the rules above. That means something like this is a NO-NO:
public class MyAction extends Action {
private Object someInstanceField;
public ActionForward execute(...) {
// modify someInstanceField here without proper synchronization ->> BAD
}
}
You don't need to synchronize Action classes unless you did something wrong with them like in the code above. The thing is that the entry point of execution into your action is the execute method.
This method receives all it needs as parameters. You can have a thousand threads executed at the same time in the execute method with no issues because each thread has its own execution stack for the method call but not for data that is in the heap (like someInstanceField) which is shared between all threads.
Without proper synchronization when modifying someInstanceField all threads will do as they please with it.
So yes, Struts 1 Action classes are not thread safe but this is in the sense that you can't safely store state in them (i.e.make them statefulf) or if you do it must be properly synchronized.
But if you keep your Action class implementation stateless you are OK, no synchronization needed and threads don't wait for one another.
Why is the struts action class is singleton ?
It's by design. Again the JavaDoc explains it:
An Action is an adapter between the contents of an incoming HTTP request and the corresponding business logic that should be executed to process this request
The request parameters are tied to the web tier and you don't want to send that type of data into your business logic classes because that will create a tight coupling
between the two layers which will then make it impossible to easily reuse your business layer.
Because transforming web objects into model objects (and I don't mean the ActionForm beans here) should be the main purpose of Action classes, they don't need to maintain any state (and shoudn't) and also, there is no reason to have more instances of these guys, all doing the same thing. Just one will do.
If you want you can safely maintain state in your model by persisting info to a database for example, or you can maintain web state by using the http session. It is wrong to maintain state in the Action classes as this introduces the need for syncronisation as explained above.
Is there a way to remove singleton from action class?
I guess you could extend Struts and override the default behavior of RequestProcessor.processActionCreate to create yourself an Action per request
but that means adding another layer on top of Struts to change its "normal" behavior. I've already seen stuff like this go bad in a few applications so I would not recommend it.
My suggestion is to keep your Action classes stateless and go for the single instance that is created for it.
If your app is new and you absolutely need statefull Actions, I guess you could go for Struts 2 (they changed the design there and the Action instances are now one per request).
But Struts 2 is very different from Struts 1 so if you app is old it might be difficult to migrate to Struts 2.
Hope this makes it clear now.
This has changed in Struts2 http://struts.apache.org/release/2.1.x/docs/comparing-struts-1-and-2.html
*Struts 2 Action objects are instantiated for each request, so there are no thread-safety issues. (In practice, servlet containers generate many throw-away objects per request, and one more object does not impose a performance penalty or impact garbage collection.) *
I don't know much about struts, but it appears that this changed in Struts 2, so perhaps you should switch to Struts 2?