If I define filter with default compact config
I can see the invocation like this in the call tree-1 (this is a feign client method)
But if I define filter profiled all my source package
I can't see any invocation in the call tree-2
Actually, I wish it better to see a tree node display a proxy class call hello() like this
call stack
How could I do? Jprofiler doc say if a profiled record show in first line, all other class is compact, so I think the proxy class auto generated is compact too, why this proxy class did not show in the call tree?
Try with Dr. Ingo Kegel's answer, and got call tree-3. proxy class call feign.ReflectiveFeign$FeignInvocationHandler, why proxy disappeared？
If you define the call tree filters to com.example., neither $Proxy... nor ReflectiveFeing$FeingInvocationHandler are in the profiled classes. This means that calls into such methods will go into the inherent time of the node of the last profiled class (com.example....helloA in this case) and not have separate nodes.
With instrumentation, JProfiler does not record complete call stacks for CPU profiling. If you switch to sampling, you can disable all filters and get complete call stacks.
Related
I am using pywin32 and calling the Dispatch function to create a COM object, but this means a new instance of the application is created (in this case PTV Vissim) whenever I call the function. Is it possible, instead, to attach to an already existing Vissim application? This would speed up development, since I wouldn't have to wait for the application to start every time I run a test.
This is my existing relevant code:
import win32com.client as com
Vissim = com.Dispatch("Vissim.Vissim.540")
Specifically for PTV Vissim, there is an option to start Vissim with the extension -automation (for example: vissim100.exe -automation). If you start PTV Vissim with the extension -automation, it provides PTV Vissim as a COM server in the automation mode for COM scripts that are started subsequently.
See chapter "Starting PTV Vissim via the command prompt" of the PTV Vissim Help.
In general, you can not "attach" to an existing Vissim instance as a COM server. Each client connection should be at best backed-up by an independent Vissim instance.
That being said, it is still possible to accomplish your goal, that is - use the command line switch "-automation" to launch Vissim.exe, and that running Vissim.exe will act as an automation server as you desired.
--
What is under-the-hood?
The truth is, right in Vissim.exe's startup code, CoRegisterClassObject(CLSID, pUnk, dwClsContext, flags, &dwRegister) is by default called with flag = REGCLS_SINGLEUSE.
REGCLS_SINGLEUSE simply means, after a client application has been connected to an Vissim class object as hosted by a running Vissim.exe, the Vissim class object's class factory is removed from public view (i.e., not in the OS system's Class Table anymore). This means, a new client connection will have to launch a new Vissim instance in order to obtain the class factory, hence the creation of a new Vissim instance is in order.
However, if you use the command line switch "-automation" while launching a Vissim.exe instance, that Vissim.exe will use REGCLS_MULTIPLEUSE flag to register the class factory instead. That allows multiple client connections to the same running Vissim.exe instance afterwards.
I have more detailed blog on this matter and other relevant issues here. You might want to check them out at blog.wupingxin.net
When I try to pop up a subVI, I usually use this configuration.
But, I realized I can call the subVI with this setting.
Now, I am feeling two configurations do the same work.
What is difference between two configurations?
Which configuration is recommended to call subVI?
Sub VI Node setup is NOT a method to call SubVI. It sets subVI properties such as to show front panel when called with some call method.
VI Call Configuration helps to determine when the subVI memory should load to RAM and when it should be released after the call.
Hi could you please let me know the session filter setting to be added in jprofiler to prevent tracing of jdk internal calls?
Internal calls in the java.* packages are not measured by JProfiler in any case, regardless of your filter settings.
If you define "inclusive" filters that define the profiled classes, then all other packages are not profiled.
Note that the first call from a profiled class into a non-profiled class is always shown in the call tree, it's just the further internal calls that are not measured.
I need to discard a message if a specific header is present.
I tried to implement a IMutateTransportMessages and call DoNotContinueDispatchingCurrentMessageToHandlers() method inside MutateIncoming but the message is dispatched to handlers anyway.
I can discard the message using an handler but I don't like it because I need also to specify the handlers' order.
Any solution?
Thanks,
Federico
I don't think this will be possible from a message mutator. After all, this isn't really the kind of activity a message mutator should be doing - it has nothing to do with changing the structure of the message.
I agree with you that it sounds messy to do this in a handler, because you're right - then you are very dependent upon the handler order.
Discarding a message due to the presence (or absence) of a header is an infrastructure concern, and since you are using NServiceBus V5, the best way to customize the infrastructure is by customizing the message handling pipeline.
Here's the relevant documentation that covers creating a behavior and inserting it into the pipeline but here's the short version:
You need to create a behavior that implements IBehavior<IncomingContext>. All of the behaviors together form a behavior chain that progress to the next step by calling next() - an Action present in the implementation) method.
Within the behavior, check for your header. To stop processing the message, just don't call next() and call context.DoNotInvokeAnyMoreHandlers() instead.
Create a class inheriting RegisterStep which, from its constructor, will define where in the pipeline to insert your behavior. You could register it right before the MutateIncomingTransportMessage step.
Create a class implementing INeedInitialization (note that this could be the same as the RegisterStep class) which calls busConfig.Pipeline.Register<TClassThatInheritsRegisterStep>().
Again, that's the short version. Check out the docs for the full story and an example.
Shameless plug: This process is also described in detail in Learning NServiceBus - Second Edition in Chapter 7, with an example.
I know how to use the FileSystemWatcher class, and I know how to send the message I want to send. What I can't figure out is where to initialize the FileSystemWatcher.
I'm assuming that there's some place to initialize an Endpoint where I could set this up, but I'm not certain where that would be.
Seems like this would be a common use-case; I'm a little surprised that Udi hasn't built this into NServiceBus!
Yes that is built into NServiceBus.
You need to implement a class that derives from IWantToRunWhenBusStartsAndStops.
See http://docs.particular.net/nservicebus/the-nservicebus-host#custom-initialization-and-startup for more info.
I'm going to try the following and tell you if it worked:
Create a FileWatcher class with
a. a static boolean variable 'keepChecking'
b. a static method watchFiles() which initiates the FileSystemWatcher and then stays alive with a loop that tests the keepChecking
b. the OnChange etc. FileSystemWatcher event handlers
- which upon being triggered by the FileSystemWatcher, presumably send out NServiceBus events
To start the watcher (in my NSB Host program) You run the WatchFiles() method in a separate thread in a starter class which inherits from IWantToRunWhenBusStartsAndStops.
To stop the watcher you first set the watcher.EnableRaisingEvents to false then set the keepWatching to false so the loop ends.
A similar approach in this StackOverflow question with code:
NServicebus with File System Watcher from Tylor Day.
Except that he unified the starter class with the filewatcher class and its (non-static) creation method running in the same thread. Interestingly it works without the need for a keepalive loop, since the FileSystemWatcher event-subscription is defined as static.
He was told that this is not the best way to go and was given two suggestions: a. To use a "satellite class" or b. To move the whole thing to a separate class, making the fileWatcher itself static. No mention of a keepalive loop. I'll try that too.