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.
Related
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.
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 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.
I have a problem with the dnn module communication. I have a module that implements the module communication interface both listener and sender. in this module, I have a placeholder where I load a new ascx control. the problem is when I want to Communicate from this new dynamically loaded control. In this control i also implemented module communication interfaces( listener and sender). but when I call sender method, in this dynamic loaded control to update an other module (on same page)nothing happens. But then i call a " sender " from the dynamic loaded controls container control( the control where i have the placeholder) it works updating the other module on the same page. It seams that module comunications do not work in dynamic loaded ascx controls at all.
Is there anyone who have any idea , to solve this
/theonealf
I would guess that it's a timing issue. Try loading your dynamic control in the Init event, and see if it will catch the communication being sent.
Agree with #bdukes, Also there are additional things that I would recommend to check:
Check if there is any exception while nothing happens
Does your control inherits from PortalModuleBase? This will be required if you want to use moduleId, UserInfo, PortalId or any other dnn specific objects.
There can be other checks but it depends on your answer by trying above and #bdukes suggestion.
Honestly, I have had limited success with the communications interface. If you can get to work for your needs, then excellent. In case you find you need another solution, here's what I've done:
If I understand the question correctly, you're concerned with the specific use-case where one module needs to communicate with another module during the loading of a page. If that is so, you most likely have one module which is the one that needs to communicate, and one or more modules which need to pick up that communication.
I've used Context.Items in combination with the ASP.NET life cycle to solve this problem. The Items collection is just a bag that anything can be stuffed into or pulled out of. The module that needs to communicate can put things into that item bag during Page_Load:
var item = "My Thing";
Context.Items.Add("MyThingKey", item);
The modules which need to consume that thing can pull things out of that bag during PreRender.
var item = Context.Items["MyThingKey"].ToString();
The key is doing this during PreRender. This way, you are assured that the consuming of the communication happens after the production of the communication.
Good luck!
I'm working with JNI and trying to unload (destroy) the VM using DestoryJavaVM function (I first call DetachCurrentThread method). It seems like the it has now influence on the VM and it is still up after the call. I read in old Sun posts that DestoryJavaVM had problems in the past (JDK1.1-1.3 in 2001) but I'm using JRE 6 and it probably should work now, right?
I need to Load\Unload a VM in the same living process since each loading requires another classes to load. Any ideas how it can be done?
Additional info:
At the unloading phase I can successfully detachCurrentThread and destroyVM (both return JNI_OK). I even FreeLibray (jvm.dll) successfuly (return 1).
When I try to Load the JVM again I can LoadLibrary(), then find the CreateVM function in the DLL and the call to CreateVM fails (return -1). What I'm doing wrong here?
Thanks,
Guy
Although it wouldn't answer your question on DestroyJavaVM.
OSGi comes to my mind you could put all classes in a bundle activate it run code and deactivate it, later you use another bundle. See Apache Felix.
Another option less elegant would be to exit the vm and restart it with another classpath.
You might check for errant threads. The Invocation API: Unloading the VM mentions, "The VM waits until the current thread is the only non-daemon user thread before it actually unloads." This is required by the Java Language Specification, 12.8.
DestroyJavaVM() doesn't support VM unloading.
DestroyJavaVM
Unloads a Java VM and reclaims its resources.
Any thread, whether attached or not, can invoke this function. If the current thread is attached, the VM waits until the current thread is the only non-daemon user-level Java thread. If the current thread is not attached, the VM attaches the current thread and then waits until the current thread is the only non-daemon user-level thread.
[...]
Unloading of the VM is not supported.
The documentation can seem a bit conflicting at first. What you can do is destroy your VM without problems, but since it doesn't unload properly you can never reload it again in the same process.
For any newbies visiting this question, refer Calling JNI_CreateJavaVM function twice
Short answer: You CANNOT create more than one JVM in a single process (this is by design).