I was using the start() method to instantiate the connection to the feed I was using and then stop() to tear it down, but after creating the Endpoint, Camel proceeds to call start() twice in a row on it
while obviously easy to work around by either checking whether its been started once already, or (as I did) just moving the starting code into the constructor of Endpoint - it's making me think I don't understand what the start() method is trying to achieve (the documentation helpfully suggests: start() starts a service ... grrreat
why would this happen twice?
incidentally createEndpointUri() gets called too... which makes me rather suspicious since this is a 'lazy loader for when a uri hasn't been supplied' ... except that one has been supplied ... so I wonder if some secondary instantiation is occuring for some reason
You should extend ServiceSupport which has doStart | doStop methods, and can keep track of the state of your class. Then Camel knows the state and wont invoke doStart twice.
Related
I have a Settable Future object "temp" which has a context set to it. Also temp.addListener(new Runnable{...}) method is called, basically registering a listener to it. However eventually if any exception comes up then temp.setException() is called. If the setException is called will the listener be de-registered or will the context be cleared (basically will the Settable Future object be damaged after exception is set)?
The flow of code is something like this :-
temp.setContext({temp.set(//some value is set if everything goes right) || temp.setException(//set exception if something comes up)});
temp.addListener(new Runnable{ run(){temp.get()}})
When you call setException(), the ListenableFuture will run its listener. If you want to write code that will not be run in that case, you can use Futures.addCallback instead of addListener. (addCallback lets you specify code to be run only in case of success or only in case of failure.)
As for what happens with the context: The context isn't part of the ListenableFuture API. I don't know if it was added by you or another library. You'd have to consult that class to find out how it behaves.
So the title says it all, what happens when during asynchronous invocation of a method performed by Java EE Container, there is a call to another method that is also annotated with #Asynchronous. I would expect that there will be one more asynchronous invocation. However the specification does not say anything about this, so could this also be Application sever vendor specific?
Currently I am analyzing the performance of a Java EE application that runs in Websphere. And I clearly see within the method tree that the second asynchronous method will actually be synchronously called. This actually makes sense for me, because we are already in some kind of asynchronous context, so instead of submitting new task we can just execute it right away..
Any idea about this?
This works. The second call will just post a request to execute that method to some internal queue that the AS maintains.
BUT... be very careful with waiting on the results from any Future that the second method might return. If the second method is a void method it's always safe.
I was reading about servlet's life-cycle and got this doubt. Can we call servlet's init and destroy method inside overridden servlet's service method like calling any other java method? Will this affect container's actual flow ?
You certainly can call init and destroy from the service method. Depending on what those methods do, i.e. if they actually destroy the servlet, this is probably unwise.
Say, for example, I have a request that comes in and encounters a problem. I think the easiest way to solve this is to call destroy and then init to "restart" the servlet.
My restart takes non-zero time, another request comes in during that time. This request encounters a problem. It also decides to restart the servlet.
You see where this is going...
I would recommend against fiddling with the servlet lifecycle methods and leave that to the container. If you must call those methods then be very wary of thread synchronisation.
As far as affecting the "container's actual flow" - the container has no way of knowing you called the method and that is why requests keep flooding in. The container will be obliviuous to you calling those methods.
Yes, you can call them, but there is no need to do this. This method used by Servlet containers.
You should use this method if you need to for example initialize internal state.
Methods init() and destroy() defaulty are empty and you should override them to take/release resources (for example).
You can call them and it will not affect servlet lifecycle.
you can call those methods no problem.But they are life cycle methods.Whatever the operations performed by the container that is servlet class instantiation and destroy will not happen at that time.
Whenever called by the container only those operations will happen(object instantiation and destroy)
In GWT I have class MyClass that registers some event handlers. There is an object (object1) of MyClass that, at a specific moment, I want to finalize and make its handlers stop listening, because after that I am going to create a different MyClass object (object2).
How can I do that? I already tried with object1 = null, but its handerls keep listening (at least for a while).
The handlers might still exist because the gc didn't get around destroying them.
If it is important that the listeners don't continue to exist then they need to be deregistered.
One way to do this is by deregistering the HandlerRegistration. For example a addClickHandler returns a HandlerRegistration which can be deregistered. When and how to do this depends on your GUI classes. You could put the deregistration in your finalize method but you will probably find that these methods are called very sporadically because of the gc and of course because this is not java but javaScript. So concider putting them in a detach or destroy method of your gui element onDetach or onUnload.
By way of some library, I find myself calling this function twice concurrently on a single instance (using the implementation returned by Executors.newSingleThreadScheduledExecutor). The Runnable passed to the second call seems not to execute, neither immediately nor on the next scheduled slot, and no exception is raised. If I serialize the two calls (did this very crudely and unintentionally by putting a breakpoint before the second caller's scheduling call), then the second runnable is executed with no issue.
I'm new to this interface, but it doesn't seem like these scheduling functions are designed to be reentrant. But I can't find anything in the various documentation describing what should happen here.
Well, small test case doesn't reproduce the problem, so I have no reason to believe the function isn't reentrant. What actually fixed the problem was to remove all this from request time to server start. There were some other signs, like the breakpoint temporary fix I mentioned in the OP, that point to some awful timing issue, somewhere in my stack.