I have experimentally established that after restarting the operator, Reconcile is called for each object that the operator is watching. Is it guaranteed or is it a side effect of something?
It's guaranteed / is intentional behavior where the objects in the initial List to populate the cache are sent as create events to the relevant handlers. The reasoning being that resources could be stale by the controller not having been running.
In fact this can cause some issues if for example your controller is watching configmaps as the memory usage of the controller pod on startup may be extremely high or exceed resource quotas.
Related
I'm struggling to understand how timed games work together with (broadcast) synchronization in UPPAAL (TiGa / Stratego). Imagine the following example:
Forcing the environment
Here, the edge receiving an event over the broadcast channel a is controlled by the environment. From what I understand, the semantics of broadcast synchronization enforce a transition in P2 from the initial state to P2.F as soon as the event is sent in P1 (assuming edge P2.<init> -> P2.F is enabled).
So naturally I would expect a strategy to exist for the controller to force the environment to transition to P2.F. This strategy would simply tell the controller to take the transition P1.<init> -> P1.F.
However, when calling the query control: A<> P2.F, UPPAL TiGa and Stratego tell me that there is no such strategy and that the counter-strategy for the environment is to stay in P2.<init> is simply wait forever.
Being forced by the environment:
When controller and environment switch sides, it looks a little different.
In that case, the query control: A[] (not P2.F) is not satisfied, indicating that there is no chance for the controller to prevent the environment from forcing a transition to P2.F.
In both examples A[] P1.F imply P2.F and E<> P1.F hold.
I'm curious about why the environment seems to be able to evade a transition that a controller can't, or if anyone can point me to some place where the timed game semantics of UPPAAL TiGa or Stratego are explained in detail.
Thank you all!
We have an MVC application using downstream web services via wcf.
We followed the proposed approach of registering a singleton ChannelFactory, which will create a channel InstancePerDependency (if I am not mistaken).
We observe the following issues in production:
Profiling shows that an inordinate amount of time is spent in System.ServiceModel.Channels.ServiceChannelFactory.ChannelCreated (few 100ms, occasionally multiple seconds). The only thing that can take any significant time in that method is acquiring a lock.
Performance counters show linear increase in CLR > Lock and Thread > Contention Rate / sec over time.
I suspect that somehow channels are not properly disposed. The ChannelFactory keeps a list of all channels (OnCreated adds the new Channel to the list, after acquiring the lock). When a channel is closed, or Aborted it gets removed from the list, after acquiring the lock. If the list becomes huge the removal can take long, and OnCreated has to wait for the lock.
We have the autofac resolved IService injected in Controller methods, and in some instances also use DependecyResolver.Current.GetService. My understanding was that the autofac WCF integration would take care of the disposal. Is that not so? What's the proper way to ensure Channel disposal?
The suspicion voiced in the question turned out to be true, channels were leaking.
There were two issues with the application at hand:
the IService dependency resolution was registered with default perDependency instance scope, resulting in a ton of channels being created. In a web application you probably want to use the perHttpRequest scope for wcf client channel resolution. (this alone should not have resulted in a leak though)
In Global.Application_Start a global filter resolved via autofac was registerd. The constructor of that filter class took a func<IDependency> as a constructor argument and some sub dependency of it had a dependency on IService. The func was only evaluated from within a web request, but it appears the lifetime scope of all dependencies resolved during func evaluation was that the func was resolved in, i.e. the application. (Not 100% certain on this. But if the perHttpRequest instance scope is requested for the IService resolution, one instance, for the app lifetime, is created according to the resolution in the global filter, and never disposed, and another is created for each httpRequest, and properly disposed at the end of the request)
I have implemented client server program using boost::asio library.
In my implementation there are times when io_service.run() blocks indefinitely. In case I pass another request to io_service, the blocked call begins to execute normally.
Is there any way to see what are the pending requests inside the io_service queue ?
I have not used work object to block the run call!
There are no official ways to query into the io_service to find all pending request. However, there are a few techniques to debug the problem:
Boost 1.47 introduced handler tracking. Simply define BOOST_ASIO_ENABLE_HANDLER_TRACKING and Boost.Asio will write debug output, including timestamps, an identifier, and the operation type, to the standard error stream.
Attach a debugger dig through the layers to find and examine operation queues. This answer covers both understanding handler tracking and using a debugger to examine an operation queue for the epoll_reactor.
Finally, if you believe it is a bug, then it may be worth updating to the latest version or checking the revision history for relevant changes. Regardless, describing the problem in more detail may allow others to help identify the source of the problem and potential solutions.
Now i spent a few hours reading and experimenting (i need more boost::asio functionality for work as well) and it turns out: Kind of.
But it is not as straightforward or readable as one might hope.
Under the hood (well, under the outermost hood) io_service has a bunch of other services registered, which do the work async_ operations of their respective fields require.
These are the "Services" described in the reference.
Now sadly, the services stay registered, wether there is work to do or not. For example if your io_service has a udp socket, it will still have all the corresponding services, even if the socket itself is inactive.
But you can ask your io_service which services it has. Lets say you want to know wether your io_service called m_io_service has an udp datagram_socket_service. Then you can call something like:
if (boost::asio::has_service<boost::asio::datagram_socket_service<boost::asio::ip::udp> >(m_io_service))
{
//Whatever
}
That does not help a lot, because it will be true no matter wether the socket is active or not. But after you know, that you have that service, you can get a ref to it using use_service instead of has_service but with the same elegant amount of <>.
And now you can inspect the service to see what it is up to. Sadly, it will not tell you what the outstanding handlers names are (probably partly because it does not know them) but if it is a socket, you can get its implemention_type and with that check whether it currently is_open or find either the local_endpoint as well as the remote_endpoint.
In case of a deadline_timer_service you can, among other stuff, find out when it expires_at.
See the reference for more information what the service is and is not willing to tell you.
http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference.html
This information should then hopefully allow you to determine which async_ operation did not return.
And if not, at the very least you can cancel any unexpectedly active services.
I'm trying to build an OS X mail client using MailCore2, and I need to know what current operations are currently running, and in what state they are — think Mail.app activity monitor window.
I've some things that I could use in the API : The MCOIMAPSession object has a operationQueueRunningChangeBlock property, but it only tells me when the session changes states (running => not running) but that is insufficient.
Right now I think I'll have to subclass/wrap those to do what I want.
MailCore does not provide an API to track running operations, nor should we, because that is your job. A typical pattern to implement this would be to either subclass the operation classes to tag each one with some kind of activity object, or aggregate activities in a separate queue and push and pop as operations are enqueued and dequeued respectively. The completion blocks of each request in the Objective-C interface should provide enough of the state of each operation for you, and some specific kinds of operations even include progress blocks/hooks.
i've tried to run mule on 3 cases in order to test it's mem usage:
One case is where i had a quartz generator create an event that a filter (right after it in a flow) allways stopped (Returned false) - meaning the flow did absolutly nothing.
In another case i did not use the filter but just used that flow to send a custom object to a WCF service running on another computer (using a cxf endpoint)
Also, i've checked what happened when i leave the flow as is but drop the wcf servce (meaning a lot of socket connection exceptions were thrown).
I did this because i am building a large app that would need this bus to work at all times (weeks at a time).
In all of those cases, the mem usage kept rising. (getting as high as 200mb ram after a few hours)
Any specific reasons this could happen?? What is causing mule to take more memory, in all of these cases?
Off the top of my head I'll stick with thread pool lazy initialization as explanation for this behavior. As time goes on and usage gets higher, the thread pools will get fully initialized.
If you want proof evidences take a look to this approach, or this one (with enableStatistics).