I'm the maintainer of the Miniprofiler Glimpse plugin and with the latest Miniprofiler versions I'm not able to push data to Glimpse because the Profiler is not yet populated (in previous versions it was) when the GetData() method of the tab is called.
Right now what I do is wrap the Miniprofiler Storage and when the Save() method is called, all the needed information is there but it's too late and I don't know how to send it to the tab.
So, what is the best approach (if possible) to add this information to a tab when it's ready in Miniprofiler?
Unfortunately EndRequest is currently the last moment you can subscribe on to return the necessary data. That is the moment when Glimpse will finalize its monitoring for the given request and the moment it will persist that information to the persistence store.
Although in v1 it is possible to add data after the EndRequest but only when using the default in memory store. So you could return your wrapper, which will be empty at that moment, and it will be stored in memory, allowing you to change the wrapped content afterwards.
But the above will not work for other persistence stores. We might also change this in v2 to make it deterministic, independent of the persistence store being used.
Maybe you could have your wrapper ask MiniProfiler to calculate the results at that moment, so they can be stored, even though those results might not be 100% complete?
Related
I'm using the new 2.X NEST client. That part is important, because there were a great many breaking changes which will effect potential answers here.
Previously, I used the Glimpse Elasticsearch plugin to see the underlying queries being generated by NEST. However, it would appear that that plugin is no longer compatible with 2.X NEST. As a result, I'm trying to find a workaround to see the JSON query. The problem here is that the old way of accessing response.RequestInformation to get at the request body is gone. It seems to have been replaced with a combination of ApiCall, CallDetails, and DebugInformation. The problem here is that in all of these the request byte array is null unless you add .DisableDirectStreaming() to the ConnectionSettings instance you pass into ElasticClient. The problem there is that I'm handling all that using dependency injection with Ninject, so in something like a controller action, I have no access to the ConnectionSettings instance to make such a change. I suppose I could just add .DisableDirectStreaming() globally, but I have no idea what the potential consequences of that is and the documentation on this is frustratingly sparse.
So, there's a few avenues for an answer here, any of which I'll accept. First, if anyone has manage to get the Glimpse plugin functioning with 2.X, I'd love to know what you did. However, based on the fact that the underlying API has changed dramatically, my assumption is that the plugin is fundamentally broken until someone branches it for 2.X or Elastic comes out with their own version (which is supposedly coming at some undetermined point in the future).
Second, if there's some way to get at the request body without disabling direct streaming, and I simply missed it. I'd appreciate guidance there.
Third, if anyone has any ideas for how I can disable direct streaming at the controller action level, without affecting my Ninject setup or applying it globally, feel free to chime in.
Finally, it would be great if someone from the Elastic team can enlighten me to the effects of disabling direct streaming and what potential problems can arise from that, so I can make a determination about whether it would be wise to apply it globally or not.
With .DisableDirectStreaming() set to true, the request bytes and response bytes are buffered in memory streams to enable them to be available on the response via response.RequestBodyInBytes and response.ResponseBodyInBytes, respectively.
By default, it is set to false so the request type e.g. SearchDescriptor<T>, SearchRequest<T>, etc. is serialized directly to the request stream of the http request and similarly, the response type is deserialized from the response stream. The overhead of setting it to true is therefore keeping the request and response bytes around in memory for the lifetime of the response (and GC kicking in).
With Connection Settings, it's best to have one instance for the lifetime of the application; Serialization settings are cached per connection settings as well as caches for field and property expressions. There's no way currently to keep the request and response bytes around on a per request basis i.e. ad-hoc introspection, but I think this would be a useful addition; I'll add an issue for it :)
I'm not personally overly familiar with the Glimpse integration but I would expect it would require updating to work with NEST 2.x because of some of the changes. Having just given it a brief look, the changes look pretty straightforward. Looks like this can be done without having to set .DisableDirectStreaming() to true, but only grabbing the request bytes before they're written to the request stream.
I need to sync entities from Ms Dynamics Crm 2015 - On Premise to my 3rd party application, for this I have set a JavaScript function on the OnSave event of the Entites( eg. account) I can access all of the attributes and send them to my webservice, but the Id (GuId) of the entity!
how can I access the Id (or set it manually) on this event?!
Xrm.Page.getAttribute("accountid") or Xrm.Page.getAttribute("id") both return null, so I can not setValue using them.
Also Xrm.Page.data.entity.getId() returns "" which is probably logical, since Object has not been inserted in the db yet, this is the reason which makes inserting a runtime generated guid for the entety seems doable !
P.S.
I know I can do same thing with plugins, which I have gone through, but the problem there is that when I register my plugin for Update message it gets called a lot of times, (mostly when it has been set for invoice), this is the reason that made me go with the JScript, since the OnSave Event seems more logical than the Update Message of the plugin
As you already found out, records which have not yet been saved have no ID. That's by design (and obvious).
Also, IDs being PKs in the database, they are handled by the system and cannot be touched or hand-crafted.
Your best bet to keep a similar behavior would be a Post-Operation Create plugin living outside the sandbox (Isolation mode: None).
Another good option would be to pull data instead of pushing it: the 3rd party application can periodically fetch new records through any of the exposed APIs (REST, SOAP, SDK ... there are many options).
In MVC and most other service frameworks I tried, caching is done via attribute/filter, either on the controller/action or request, and can be controlled through caching profile in config file. It seems offer more flexibility and also leave the core service code cleaner.
But ServiceStack has it inside the service. Are there any reason why it's done this way?
Can I add a CacheFilterAttribute, but delegate to service instead?
ToOptimizedResultUsingCache(base.Cache,cacheKey,()=> {
// Delegate to Request/Service being decorated?
});
I searched around but couldn't find an answer. Granted, it probably won't make much difference because the ServiceStack caching via delegate method is quite clean. And you seldom change caching strategy on the fly in real world. So this is mostly out of curiosity. Thanks.
Because the caching pattern involves, checking first to see if it is cached, if not to then execute the service, populate the cache, then return the result.
A Request Filter doesn't allow you to execute the service and a Response Filter means that the Service will always execute (i.e. mitigating the usefulness of the Cache), so the alternative would require a Request + Response filter combination where the logic would be split into 2 disjointed parts. Having it inside the Service, lets you see and reason about how it works and what exactly is going on, it also allows full access to calculate the uniqueHashKey used and exactly what and when (or even if) to Cache, which is harder to control with a generic black-box caching solution.
Although we are open to 'baking-in' built-in generic caching solutions (either via an attribute or ServiceRunner / base class). Add a feature request if you'd like to see this, specifying the preferred functionality/use-case (e.g. cache based on Time / Validity / Cache against user-defined Aggregate root / etc).
I'm using mini profiler in my asp.net Web API project and want to track the performance of some code that runs in a custom DelegatingHandler.
The calls MiniProfiler.Current.Step() inside the DelegatingHandler don't show up in the results. Other calls in the same project show up ok.
Further investigation revealed that MiniProfiler.Current is retrieved from HttpContext.Current in the WebRequestProfilerProvider. And HttpContext.Current is null when called from DelegatingHandler.
Is there a better way to retrieve the MiniProfiler.Current so that it works inside the handler?
MiniProfiler Timings are stored in HttpContext.Current by default (as you discovered). Thus if you are calling MiniProfiler from a place where HttpContxt.Current is null, the results cannot be saved. The solution is to save (and retrieve) the results from somewhere else.
MiniProfiler offers the option of the option of changing the location where all results should be stored and retrieved from (using MiniProfiler.Settings.Storage). The new v3 MiniProfiler (beta nuget here) offers the option of configuring different IStorage for each request, and for using a MultiStorageProvider to designate multiple locations into which results can be stored and retrieved. You can see an example of this in the Sample.Mvc project on github.
In your case, the best approach might be to set a MultiStorageProvider for your global MiniProfiler.Settings.Storage that will first save/retrieve from HttpRuntimeCacheStorage and then afterwards will use some other IStorage that is accessible from the DelegatingHandler. Then in the DelegatingHandler, set the MiniProfiler.Current.Storage to only use the second storage option that you set in the MultiStorageProvider (since it is pointless to try to save the the HttpCache). In this was, profiles from the DelegatingHandler will be saved into your second storage option, and will be retrieved for view with your other results (since MultiStorageProvider will Load results from the first place it can get them - if it doesn't find the result in HttpCache, it will go to the second option.
Note - having multiple storage options is useful in this case, but it can have a negative impact on the performance of retrieving profiles.
I'm new with AppFabric Server caching but after playing around with it everything has been working like a dream.
I can add for example datatables to my cache and get that back to use just fine.
I got exited about this functionality and tried to test this with one 3rd party vendors dll that includes login session data (session id, date's etc.)
I created WCF service with method where you consume this dll to login and I store that session to my cache.
This works just fine and I can verify this by looking at statistics of my cache with PowerShell.
Then I created another method that is supposed to pick up this cached session and use it to execute actions. This is where I'm running to the wall.
I can see that I have been able to get session from cache, but information within session object is null (session id, date's...)
I've been serching help for this from everywhere but nobody seams to face this issue.
So my question is
Can AppFabric server cache ALL field values of given object (Public/Non-public not having any role)?
Is there any way to see actual existing content of cache where you would see keys and cached objects with values?
Thanks for all possible comments!
Regards
Mikko
In AppFabric you can only cache objects that are serialisable (or serializable for US readers :-) ). The fact that you have been able to store your session objects in the cache suggests that they are indeed serialisable. But to figure out what's going on here we'll need to probe a little deeper.
By default with binary serialisation, all fields/properties of an object are serialised, public and private (whereas XML serialisation only picks up the public values). We aren't told which flavour of serialisation AppFabric uses, but binary serialisation tends to be more efficient so it's a reasonable assumption that that's what gets used under the covers. However, it's possible to override the serialisation behaviour using the NonSerialized attribute, so that items marked NonSerialized don't make it into the serialised version of the object. The MSDN page for Selective Serialisation specifically advises that security-sensitive information should be marked as nonserializable.
A session ID definitely comes under the heading of security-sensitive information as it's key for session hijacking, so I should say that's the problem you're facing. You could confirm this by having a look inside the 3rd party DLL with ILDasm or Reflector to see if the fields inside the session class are indeed marked as not serialised.
Can you get round this? Well there is, of course, nothing to stop you creating your own Session class that you populate from the 3rd party's object where you keep all the properties serialisable and caching that instead. Bear in mind, however, that you're then essentially doing the very thing they've tried to stop you doing...