Is there a way I can tell if an AmazonS3Client has been shutdown?
Bellow is the scenario I'm trying to achieve to avoid creating new clients every time and to make sure if some other component shutdowns it (by mistake) it wont break the next requests.
private AmazonS3ClientBuilder createBuilder() {
return AmazonS3ClientBuilder.standard()
.withCredentials(InstanceProfileCredentialsProvider.getInstance();)
.withRegion(clientRegion);
}
public synchronized AmazonS3 buildAmazonClient() {
if (s3Client == null || s3Client.*IS_SHUTDOWN?*)
s3Client = buildAmazonClient();
return s3Client;
}
According to Amazon SDK Developer Guide:
Service clients in the SDK are thread-safe and, for best performance, you should treat them as long-lived objects. Each client has its own connection pool resource
and Amazon SDK Reference:
This is an optional method, and callers are not expected to call it, but can if they want to explicitly release any open resources
So although there doesn't seem to be any method to check if it's already shutdown (i.e. the client is unusable any longer to make requests), it seems you could manage it yourself, but you don't really need to:
Since it's a long lived object you shouldn't create too many instances, and optionally invoke shutdown once you no longer plan on accessing them.
If you really have a use case in which you need to instantiate and kill different instances throughout the lifetime of your application, I'd suggest you keep tabs on your shutdown invocation, so you can tell if it's been shutdown already (although once the resources are freed, there shouldn't be a real need to keep a reference to a shutdown client any longer...)
Related
Hi I have a method that is executed by multiple threads concurrently to connect to the s3 bucket objects and read metadata. All those methods are using a single s3 client object. Based on the Amazon Java SDK documentation I found that the s3Clients are thread safe objects. Can the following way of implementation cause any deadlock or performance issue? Is this the correct way of implementation when using multiple thread with s3 client?
public class S3Client {
// static method that returns the s3 client for all the requests
public static AmazonS3 getS3Client(){
return AmazonS3ClientBuilder.standard().withRegion(Regions.DEFAULT_REGION).build();
}
}
And there is another class(RequestHandler->readObject method) that will be executed by multiple threads concurrently. Hence will be executed for each and every requests.
public class RequestHandler {
// Multiple concurrent threads are accessing this method
public void readObject(){
AmazonS3 s3Client = S3Client.getS3Client();
ListObjectsV2Result result = s3Client.listObjectsV2("bucket_name");
}
}
Please advice. Thanks in advance!!
Lets go one by one:
The builders in the java AWS S3 sdk are generally not thread safe. So
try not to use S3Client#getS3Client() in multi-threaded environment.
AmazonS3Client is annotated with #ThreadSafe. This is an annotation in Java AWS sdk, that marks the class as thread-safe. So there is no need to create some sort of object factory like you did, you only can have one AmazonS3Client singleton object per application. In the examples above you clearly create new instance per each and every RequestHandler#readObject() method invocation. It is not only unsafe, it will likely cause a performance issue, since you will create a lot of AmazonS3Client, which will degrade your java app garbage collection process.
You can solve pretty much all of it if you will just use a singleton pattern, i.e create AmazonS3Client as a singleton object, either by spring, or by any other IoC framework, or by yourself, for example via double check locking. In this way you will achieve thread safety along with relatively good performance (in comparison to code in the question).
Hope it helped, have a nice day!)
I am trying to integrate QFJ into a single-threaded application. At first I was trying to utilize QFJ with my own TCP layer, but I haven't been able to work that out. Now I am just trying to integrate an initiator. Based on my research into QFJ, I would think the overall design should be as follows:
The application will no longer be single-threaded, since the QFJ initiator will create threads, so some synchronization is needed.
Here I am using an SocketInitiator (I only handle a single FIX session), but I would expect a similar setup should I go for the threaded version later on.
There are 2 aspects to the integration of the initiator into my application:
Receiving side (fromApp callback): I believe this is straightforward, I simply push messages to a thread-safe queue consumed by my MainProcessThread.
Sending side: I'm struggling to find documentation on this front. How should I handle synchronization? Is it safe to call Session.sendToTarget() from the MainProcessThread? Or is there some synchronization I need to put in place?
As Michael already said, it is perfectly safe to call Session.sendToTarget() from multiple threads, even concurrently. But as far as I see it you only utilize one thread anyway (MainProcessThread).
The relevant part of the Session class is in method sendRaw():
private boolean sendRaw(Message message, int num) {
// sequence number must be locked until application
// callback returns since it may be effectively rolled
// back if the callback fails.
state.lockSenderMsgSeqNum();
try {
.... some logic here
} finally {
state.unlockSenderMsgSeqNum();
}
Other points:
Here I am using an SocketInitiator (I only handle a single FIX session), but I would expect a similar setup should I go for the threaded version later on.
Will you always use only one Session? If yes, then there is no use in utilizing the ThreadedSocketInitiator since all it does is creating a thread per Session.
The application will no longer be single threaded, since the QFJ initiator will create threads
As already stated here Use own TCP layer implementation with QuickFIX/J you could try passing an ExecutorFactory. But this might not be applicable to your specific use case.
I want to create an application that can detect other instances of itself and prevent them from running. To accomplish this, I'm thinking of opening up a new ServerSocket on some application-specific port, and then relying on the exception that should be thrown if I try to bind to the same port more than once to "detect" and kill duplicate application instances. I know I could do something like write a file into the present-working-directory and "detect" it to accomplish the same sort of behavior, but I really don't want to do this (what happens if the app dies and can't remove the file?), so that's why I've chosen the ServerSocket route.
Let's say I have the following code:
public class MyClass{
public static void main(String[] args) throws IOException{
new ServerSocket(1234);
new Thread(){
//This is a non-daemon thread. Assume its run() method never returns.
}.start();
}
}
Question
Short of creating the ServerSocket, my application never really needs to use it again, because its mere existence allows me to detect when another instance of my app attempts to start up. Thus, saving a reference to said ServerSocket will result in a compile warning (unused reference). I'm a neat-freak, so I'd rather not save a reference if I can avoid it. My question is, will this ServerSocket instance get garbage collected before all non-daemon threads exit (assuming the app doesn't fail or exit some other way), and if so, will its associated port become unbound as a result?
I'm confused: you're a "neat freak" but would rather leave socket closing to the whims of the garbage collector than have a close procedure under the control of the application in the case of a normal exit? (I assume this to be the case, because to put such a mechanism in place you would need to hold a reference, thus eliminating your perceived problem.)
For what it's worth, I don't think that there'll actually be a problem in practice if you don't hold on to the reference:
internally, it is likely that a reference will be held while the socket is bound
it is likely that the ServerSocket's close() method will be called on garbage collection. It is called in the finalize() method of AbstractPlainSocketImpl, so in principle will be called, with the proviso that there is no guarantee that any finalize method will actually get called.
if the application terminates abnormally, there is no guarantee that the socket will be unbound immediately, though on recent O/Ses it is likely to be (best to test this).
However, I would really recommend coding a "clean" shutdown mechanism for the case where your app is shut down cleanly, and for that you will need to hold on to a reference to the socket. So I think you're really inventing a problem for yourself that need not exist if you just use sensible programming practice instead.
OK, let me try to redeem myself from my previous wrong understanding. The file lock and socket techniques that you mention are widely used but there is another one - having an observer that will keep the current instance of yor program (through methods register and deregister).
If a new instance tries to register while there is another one running, the registration process will fail and your application could close gracefully.
Your application could then implement an interface Observable that would contain one method beObserved in order for your observer to know that your application is still alive. Therefore, if your application crashes, the periodic check would fail and it would deregister the crashed application automatically.
I develop an application using the Play! Framework which makes heavy use of the javax.script Package, including the ScriptEngine. As ScriptEngines are expensive to create and it would make sense to use them across multiple requests (I don't bother to create multiple ScriptEngines, one per Thread - at least i won't create ScriptEngines for each Request over and over).
I think this case is not restriced to ScriptEngines, there might be something in the framework I'm not aware of to handle such cases.
Thank you for any ideas you have!
Malax
Play is stateless, so there is no "session-like" mechanism to link an object to a user. You may have 2 alternatives:
Use the Cache. Store the ScriptEngine in the cache with a unique ID, and add a method that checks if it's still there. Something like:
public static Engine getScriptEngine(Long userId) {
String key = "MY_ENGINE" + userId;
ScriptEngine eng = (ScriptEngine) Cache.get(key);
if(eng == null) {
eng = ScriptEngine.create();
Cache.put(key, eng);
}
return eng;
}
Or create a singleton object that contains a static instance of the ScriptEngine so it's always there once the server starts.
I would say the Cache one is the best approach.
EDIT: on your comment, this will depend on situation:
If you want to reuse a Engine across multiple request of a unique user (that is, each user has his own ScriptEngine to work with) the cache method works as the cache links the Engine to the user id. This would solve any threading issue too.
Otherwise, if you want to reuse it across multiple requests of multiple users, the static method is a better approach. But as you mention the access won't be thread safe, in Play or in any system.
I'm thinking your best bet is to work asynchronously with them. I don't know how you will use the ScriptEngines, but try to do something like this:
On request, store an entry in a table from the db marking a ScriptEngine processing request
In the same request, launch an asynchronous job (or have on running every 30 seconds)
The job will read the first entry of the table, remove it, do the task, return answer to the user. The job may have a pool of ScriptEngine to work with.
As jobs are not launched again while a current job is working, if you have enought requests the job will never cease working. If it does it means that you don't need engines at that time, and they will be recreated on demand.
This way you work linearly with a pool, ignoring threading issues. If you can't do this, then you need to fix the thread-safety of your ScriptEngine, as you can't pretend to share an object that it's not thread safe in a server environemnt which spawns multiple threads :)
Why don't you implement a Script-Pool? So each request get a instance from the pool the same way as a JDBC-Connection-Pool.
But make sure the Script-Engine is stateless.
I have the following situation. I have a job that:
May time out after a given amount of time, and if so occurs needs to throw an exception
If it does not time out, will return a result
If this job returns a result, it must be returned as quickly as possible, because performance is very much an issue. Asynchronous solutions are hence off the table, and naturally tying up the system by hammering isn't an option either.
Lastly, the system has to conform to the EJB standard, so AFAIK using ordinary threads is not an option, as this is strictly forbidden.
Our current solution uses a thread that will throw an exception after having existed for a certain amount of time without being interrupted by an external process, but as this clearly breaks the EJB standard, we're trying to solve it with some other means.
Any ideas?
Edited to add: Naturally, a job which has timed out needs to be removed (or interrupted) as well.
Edited to add 2:
This issue doesn't seem to have any solution, because detecting a deadlock seems to be mostly impossible sticking to pure EJB3 standards. Since Enno Shioji's comments below reflect this, I'm setting his suggestion as the correct answer.
This is more like a request for clarification, but it's too long to fit as a comment..
I'm not sure how you are doing it right now, since from what you wrote, just using the request processing thread seems to be the way to go. Like this:
//Some webservice method (synchronous)
public Result process(Blah blah){
try{
return getResult(TimeUnit.SECONDS, 10);
}catch(InterruptedException e){
//No result within 10 seconds!
throw new ServiceUnavailableException("blah");
}
}
I'm not sure why you are creating threads at all. If you are forced to use threads because the getResult method doesn't timeout at all, you would have a thread leak. If it timeouts after a longer time and thus you want to "shortcut" your reply to the user, that would be the only case I'd consider using a thread like I imagine how you are using it. This could result in Threads piling up under load and I'd strive to avoid such situation.
Maybe you can post some code and let us know why you are creating in your service at all?
Also, what's your client interface? Sounds like it's a synchronous webservice or something?
In that case, if I were you I would use a HashedWheelTimer as a singleton... this mechanism should work great with your requirement (here is an implementation). However, this unfortunately seem to conflict with the ban on threading AND the ban on singleton in the EJB spec. In reality though there really isn't a problem if you would do this. See this discussion for example. We have also used the singleton pattern in our EJB app. which used JBoss. However, if this isn't a viable choice then I might look at isolating the processing in its own JVM by defining a new web service (and deploy it in a web-container or something), and call that service from the EJB app. This would however obviously incur performance hit and now you would have another whole new app.
With Bean Managed Transaction, the timeout for the specific transaction can be specified by using UserTransaction interface.
Modify the timeout value that is
associated with transactions started
by the current thread with the begin
method.
void setTransactionTimeout(int seconds) throws SystemException
Transaction will timeout after specified seconds & may not get propagated further. If exception is not thrown implicitly, then can throw it explicitly based on the result.
Will return a result on successful completion within specified time.
Can use it with stateless session beans so there may not be a performance issue.
Its EJB standard so that will not be an issue to implement.
With little-bit work around, it should work fine in the given scenario.
Edit : Also can use server specific properties to manage transaction timeout.
JBoss : At either at class or method level annotation #TransactionTimeout(100) can be applied.
Weblogic : Specifying the parameters in weblogic-ejb-jar.xml
<transaction-descriptor>
<trans-timeout-seconds>100</trans-timeout-seconds>
</transaction-descriptor>
GlassFish : Using the optional cmt-timeout-in-seconds element in sun-ejb-jar.xml
Stick the process and it's timeout thread in to a class annotated with #WebService, put that class in to a WAR, then invoke the WebService from your EJB.
WARs don't have the same limitations or live under the same contract that EJBs do, so they can safely run threads.
Yes, I consider this a "hack", but it meets the letter of the requirements, and it's portable.
You can create threads using the commonj WorkManager. There are implementations built into WebSphere and Weblogic as they proposed the standard, but you can also find implementations for other appservers as well.
Basically, the WorkManager allows you to create managed threads inside the container, much like using an Executor in regular Java. Your only other alternative would be to use MDB's, but that would be a 'heavier' solution.
Since I don't know your actual platform, you will have to google commonj with your platform yourself 8-)
Here is a non IBM or Oracle solution.
Note: This is not an actual standard, but it is widely available for different platforms and should suit your purposes nicely.
For EJBs, there is a concept of "Container Managed Transactions". By specifying #TransactionAttribute on your bean, or specific method, the container will create a transaction when ever the method(s) are invoked. If the execution of the code takes longer than the transaction threshold, the container will throw an exception. If the call finishes under the transaction threshold, it will return as usual. You can catch the exception in your calling code and handle it appropriately.
For more on container managed transactions, check out: http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Transaction3.html and http://download.oracle.com/javaee/5/tutorial/doc/bncij.html
You could use #TimeOut. Something like:
#Stateless
public class TimedBean {
#Resource
private TimerService timerService;
static private AtomicInteger counter = new AtomicInteger(0);
static private Map<Integer, AtomicBoolean> canIRunStore = new ...;
public void doSomething() {
Integer myId = counter.getAndIncrement();
AtomicBoolean canIRun = new AtomicBoolean(true);
canIRunStore.put(myId, canIRun);
timerService.createTimer(1000, 0, myId);
while (canIRun.get() /* && some other condition */) {
// do my work ... untill timeout ...
}
}
#Timeout
#PermitAll
public void timeout(Timer timer) {
Integer expiredId = (Integer) timer.getInfo();
AtomicBoolean canHeRun = canIRunStore.get(expiredId);
canIRunStore.remove(expiredId);
canHeRun.set(false);
}
}