I do understand that the first wcf call is usually very slow. And that is the case in my app. I have tried to apply various solutions I have found through out internet with very little progress.
But the thing that puzzles me is the fact that all subsequent wcf calls even after having exited and reentered the app after few minutes are very fast. Am I correct in thinking that android somehow keeps some dll or whatever resource related to wcf infrastructure in some memory cache so that even after reentering the app calls are fast ? If that is the case, can I use this same technique to keep "wcf resources" ready to fire for my app? (I hope my question is clear :-) Thank you in advance
Related
TLDR; is it possible to send/receive objects between an app and a 3rd party launch agent?
I'm writing an extension for an existing app (A). It's packaged and I do not have access to the source - but I can write simple plug-ins that can do some basic Cocoa and host a UI. Read: very limited options.
Ideally, what I'd like to do is have the plugin in app (A) message an external service (B) [sending objects], have (B) do some heavy lifting, then respond back to (A) so the UI can update.
I've been reading up on Launch Agents and they look promising, but I noted the examples all use basic types - no objects. I found one post discussing how to use Distributed Objects, but that's about it. It looks great, but what worries me is I'm not seeing a whole lot of current information on DO and I can't tell if it's something Apple will continue to support going forward.
Does anyone have any suggestions on options for a scenario like this? Maybe I'm just approaching this the wrong way?
Another option is I just completely split this out - write a separate full app and have (A) open it up with AppleScript. The UX wouldn't be as nice, but it would also work.
Thank you,
Eric
NOTE: I can't use NSTask. Or at least I've failed utterly to get it to work in this specific situation. Due to issues with app (A) it breaks when some of the methods run within the process. If I could somehow spawn NSTask so it was executing completely outside of (A) that might be an option. Which is actually what prompted me to look at Launch Agents...
I'm working on porting an app from iOS to WinRT/8 Metro/8 Immersive/Whatever the current name is.
On iOS, we have the ability to set Application does not run in background to YES to cause the app to actually quit whenever the user leaves the app.
I would like to figure out how to replicate this behavior in WinRT.
Yes, I understand that this is abnormal behavior.
Yes, I have thought this through.
Yes, I have an extremely good reason for doing this.
I'm assuming that during the userLeavingApp event, I would just call Application.Current.Exit(), but I can't seem to find the userLeavingApp event. I thought about using OnSuspending (Handles Me.Suspending) in App.xaml.vb, but that doesn't seem to be called quickly enough for me.
Is there a .NET equivalent of viewWillDisappear or something?
Any ideas? This is an important security characteristic of my app, and I'd hate to have such difficulty in an entire platform due to such a small issue.
Thanks!
I'm not actually seeing Application.Current.Exit() working in OnSuspending; although as you mention the suspending isn't happening fast enough for you (which is by design). Throwing an exception there didn't work for me either.
There is Window.VisibilityChanged and if I issue Exit/exception there, it does shutdown the app when another app takes over. That said, VisibilityChanged will fire under other circumstances too so not sure if you could cover all the scenarios or rely on them not changing. See here for a bit more context.
To echo #Filip, whose response just popped in, it's highly unlikely you'll pass certification. An Exit() call is tantamount to an exception.
I don't think your app will pass certification if you call Application.Current.Exit(). If you are really confident this is what you want - I guess it is worth a shot to try. You could though simply unload anything that uses memory/CPU when you exit.
Today I've been working with wkhtmltopdf.exe in a web app and I was wondering whether I should use a lock (or the singleton pattern) in order to call Process.Start in a thread-safe manner.
My concern is that multiple users will do GETs simultaneously on the page that calls the exe file mentioned above. It's my understanding that each Request is created on its own thread, does this mean that calling an exe file (with Process.Start) is thread-safe in a web application?
Process.Start has nothing to do with thread safety. It is a thread safe call - you can call it as many times you want from as many threads you want. The problem that comes with this is that you are depending on an external process to do the job. Spawning multiple processes in an intensively used web application is not a good idea as you will be consuming more and more resources. So while this could be fine if your site doesn't have a big load, it is not recommended if you expect to start scaling.
Yeah, I know that converting HTML to PDF in a reliable and performant way which doesn't involve spawning processes and be happy with the final result costs money. But scalability of a web application usually comes at a cost.
I work on a Classic ASP web application that uses several old COM components written in VB6. All of the VB6 components are registered in a COM+ application that run in their own dllhost process. A large majority of the application has been converted to .Net, but there are still a lot of legacy pages and components. COM Interop is used in both directions, calling some .Net assemblies from classic ASP and VB6 as well as calling VB6 components from ASP.Net. The application is running on Windows Server 2008 R2 (IIS 7.5) in the classic pipeline mode.
For the most part the application works fine. The transition to .Net effort was ultimately abandoned, with a new product being developed instead. In the meantime, the old product must be maintained in it's heterogeneous state.
I am having trouble tracking down an intermittent problem where the web application hangs. Users just see a blank screen while their browser waits and the server never responds. The hang persists until I manually kill the dllhost process that's hosting the VB6 components, so I believe the problem is buried there. Probably a memory leak or runaway circular loop.
There are thousands of users on the system daily, but the problem only happens once or twice a week. Fortunately we have a web farm that automatically pulls a server out when it stops responding, so the customer impact is zero. Still, I would like to figure out what's going on.
I have recompiled all of the VB6 components to include debugging symbols and redeployed to production. When the problem happens, I use the 32-bit task manager (c:\windows\syswow64\taskmgr.exe) to take a crash dump of the dllhost process. I end up with a dllhost.dmp file, which I bring down to my development workstation and open in VS2010. I have the .pdb symbol files that VB6 created in my symbols path. When I start the debugging session in VS2010, I can go to the Modules screen and see that indeed all of the symbols for my components are loaded.
Where to go from here? The call stack doesn't show any of my own components. It looks like this:
The disassembly at the top of the call stack looks like this:
Not sure what else I can do. I examined all of the locals at every frame of the call stack and it's gibberish to me. I don't see any references to any of my own components.
Perhaps WinDbg would yield more information? Not sure where to start with it.
I'm pretty sure that if I could just find what VB6 class/method was being called when the hang occurred that I could get to the bottom of it. I've tried adding some logging, and the results are inconsistent.
Perhaps there's nothing wrong with my VB6 components at all, but I'm hitting on some bug within Windows or IIS?
Any advice would be appreciated, but throwing away VB6 is not an option at this point. Thanks.
Not a complete answer, but CoRegisterSurrogateEx is documented to block as long as the surrogate process is running:
The CoRegisterSurrogateEx function is a blocking function. It does not
return until COM+ has determined that the process will be shut down.
Before calling this function, initialize COM on this thread as a
multi-threaded apartment (MTA).
So I don't think the error is on this call-stack. (You can see it was still blocking on a WaitForSingleObject call, most likely the mechanism it uses to block until the process is to be shut down).
I have an XNA application that communicates with another process (on the same computer) using WCF.
On each Update cycle, the XNA will get data from the other process.
The XNA runs fine when in a window (over 60fps),
but if I try to run it fullscreen, I'm getting less than 1fps.
This does not happen if I turn off the WCF.
Why would fullscreen affect it like that ?
Any ideas ?
Thanks.
This seems like a long shot, providing that there's not much details, but it looks to me you have some thread starvation issues, possibly caused by page flip / buffer swap waiting for something? (What OS are you using, how many cores)
You should try using the profiler and analyzing the code to see where is the critical secion.
For a quick fix, try using Thread.Sleep(1), or switching to Async calls for your WCF service.