I am using MAF for my Addin development. All seems to be working fine, but one issue needs be sorted...
I activate the plugin in their own process, i,e, using
var process = new AddInProcess();
myAddinToken.Activate(process,AddInSecurityLevel.FullTrust);
When an unhandled exception occurs in the add-in, my host crashes!
Since i am running the addin in a seperate process, why i am i still seeing my host app crash because of an unhandled exception in the ad-in?
Is it not supposed to simply crash the add-in specific dedicated process, and leave the host process as-is live?
Any ideas how to fix this?
What is the exception that crashes your app?
Do you have an UI element coming from your AddIn?
With the UI I had to close / dispose the UI elements on the host side properly and also catch RemotingException
Maybe this helps you a bit:
AddInToken grailAddInToken = addInTokens[0];
AddInProcess addInProcess = new AddInProcess();
addInProcess.Start();
Process process = Process.GetProcessById(addInProcess.ProcessId);
process.EnableRaisingEvents = true;
process.Exited += (s, e) => synchronizationService.Invoke(() =>
{
window.Close();
});
Related
I'm building a ReactJs PWA but I'm having trouble detecting updates on iOS.
On Android everything is working great so I'm wondering if all of this is related to iOS support for PWAs or if my implementation of the service worker is not good.
Here's what I've done so far:
Build process and hosting
My app is built using webpack and hosted on AWS. Most of the files (js/css) are built with some hash in their name, generated from their content. For those which aren't (app manifest, index.html, sw.js), I made sure that AWS serves them with some Cache-Control headers preventing any cache. Everything is served over https.
Service Worker
I kept this one as simple as possible : I didn't add any cache rules except precache for my app-shell:
workbox.precaching.precacheAndRoute(self.__precacheManifest || []);
Service-worker registration
Registration of the service worker occurs in the main ReactJs App component, in the componentDidMount() lifecycle hook:
componentDidMount() {
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js')
.then((reg) => {
reg.onupdatefound = () => {
this.newWorker = reg.installing;
this.newWorker.onstatechange = () => {
if (this.newWorker.state === 'installed') {
if (reg.active) {
// a version of the SW is already up and running
/*
code omitted: displays a snackbar to the user to manually trigger
activation of the new SW. This will be done by calling skipWaiting()
then reloading the page
*/
} else {
// first service worker registration, do nothing
}
}
};
};
});
}
}
Service worker lifecycle management
According to the Google documentation about service workers, a new version of the service worker should be detected when navigating to an in-scope page. But as a single-page application, there is no hard navigation happening once the app has been loaded.
The workaround I found for this is to hook into react-router and listen for route changes, then manually ask the registered service worker to update itself :
const history = createBrowserHistory(); // from 'history' node package
history.listen(() => {
if ('serviceWorker' in navigator) {
navigator.serviceWorker
.getRegistration()
.then((reg) => {
if (!reg) {
return null;
}
reg.update();
});
}
});
Actual behavior
Throwing a bunch of alert() everywhere in the code showed above, this is what I observe :
When opening the pwa for the first time after adding it to the homescreen, the service worker is registered as expected, on Android and iOS
While keeping the app opened, I deploy a new version on AWS. Navigating in the app triggers the manual update thanks to my history listener. The new version is found, installed in the background. Then my snackbar is displayed and I can trigger the switch to the new SW.
Now I close the app and deploy a new version on AWS. When opening the app again :
On Android the update is found immediately as Android reloads the page
iOS does not, so I need to navigate within the app for my history listener to trigger the search for an update. When doing so, the update is found
After this, for both OS, my snackbar is displayed and I can trigger the switch to the new SW
Now I close the app and turn off the phones. After deploying a new version, I start them again and open the app :
On Android, just like before, the page is reloaded which detects the update, then the snackbar is displayed, etc..
On iOS, I navigate within the app and my listener triggers the search for an update. But this time, the new version is never found and my onupdatefound event handler is never triggered
Reading this post on Medium from Maximiliano Firtman, it seems that iOS 12.2 has brought a new lifecycle for PWAs. According to him, when the app stays idle for a long time or during a reboot of the device, the app state is killed, as well as the page.
I'm wondering if this could be the root cause of my problem here, but I was not able to find anyone having the same trouble so far.
So after a lot of digging and investigation, I finally found out what was my problem.
From what I was able to observe, I think there is a little difference in the way Android and iOS handle PWAs lifecycle, as well as service workers.
On Android, when starting the app after a reboot, it looks like starting the app and searching an update of the service worker (thanks to the hard navigation occuring when reloading the page) are 2 tasks done in parallel. By doing that, the app have enough time to subscribe to the already existing service worker and define a onupdatefound() handler before the new version of the service worker is found.
On the other hand with iOS, it seems that when you start the app after a reboot of the device (or after not using it for a long period, see Medium article linked in the main topic), iOS triggers the search for an update before starting your app. And if an update is found, it will be installed and and enter its 'waiting' status before the app is actually started. This is probably what happens when the splashscreen is displayed...
So in the end, when your app finally starts and you subscribe to the already existing service worker to define your onupdatefound() handler, the update has already been installed and is waiting to take control of the clients.
So here is my final code to register the service worker :
componentDidMount() {
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js')
.then((reg) => {
if (reg.waiting) {
// a new version is already waiting to take control
this.newWorker = reg.waiting;
/*
code omitted: displays a snackbar to the user to manually trigger
activation of the new SW. This will be done by calling skipWaiting()
then reloading the page
*/
}
// handler for updates occuring while the app is running, either actively or in the background
reg.onupdatefound = () => {
this.newWorker = reg.installing;
this.newWorker.onstatechange = () => {
if (this.newWorker.state === 'installed') {
if (reg.active) {
// a version of the SW already has control over the app
/*
same code omitted
*/
} else {
// very first service worker registration, do nothing
}
}
};
};
});
}
}
Note :
I also got rid of my listener on history that I used to trigger the search for an update on every route change, as it seemed overkill.
Now I rely on the Page Visibility API to trigger this search every time the app gets the focus :
// this function is called in the service worker registration promise, providing the ServiceWorkerRegistration instance
const registerPwaOpeningHandler = (reg) => {
let hidden;
let visibilityChange;
if (typeof document.hidden !== 'undefined') { // Opera 12.10 and Firefox 18 and later support
hidden = 'hidden';
visibilityChange = 'visibilitychange';
} else if (typeof document.msHidden !== 'undefined') {
hidden = 'msHidden';
visibilityChange = 'msvisibilitychange';
} else if (typeof document.webkitHidden !== 'undefined') {
hidden = 'webkitHidden';
visibilityChange = 'webkitvisibilitychange';
}
window.document.addEventListener(visibilityChange, () => {
if (!document[hidden]) {
// manually force detection of a potential update when the pwa is opened
reg.update();
}
});
return reg;
};
As noted by Speckles (thanks for saving me the headache), iOS installs the new SW before launching the app. So the SW doesn't get a chance to catch the 'installing' state.
Work-around: check if the registration is in the waiting state then handle it.
I've made an (untested) example of handling this. - a mod to the default CRA SW.
I am testing a .NET Core 2.0 app which uses the Service Bus SDK to retrieve messages from an Event Hub. I setup a console app to do that, and intend to run the app as a Docker container.
This method creates the Event Host Processor which will read the messages:
private static async Task MainAsync(string[] args)
{
Console.WriteLine("Registering EventProcessor...");
var eventProcessorHost = new EventProcessorHost(
EhEntityPath,
PartitionReceiver.DefaultConsumerGroupName,
EhConnectionString,
StorageConnectionString,
StorageContainerName);
// Registers the Event Processor Host and starts receiving messages
Console.WriteLine("Retrieving messages");
await eventProcessorHost.RegisterEventProcessorAsync<EventProcessor>();
Console.WriteLine("Sleeping");
Thread.Sleep(Timeout.Infinite);
}
As the event processor implemented in class EventProcessor will be the one handling the events, I am trying to prevent the console app to exit when the registration of the Processor is finished.
However, I can't find a reliable way to keep the app alive. If I run this container as-is, all I see in the output window is:
Registering EventProcessor...
Retrieving messages
Sleeping
and no messages are ever received.
Thanks all for the suggestions.
I followed those articles but eventually ended up with this, which applies specifically to .NET Core apps:
https://github.com/aspnet/Hosting/issues/870
I've tested it and the app can shutdown gracefully when it receives a termination signal from the Docker runtime.
UPDATE: this is the relevant sample from the GH issue link above:
public class Program
{
public static void Main(string[] args)
{
var ended = new ManualResetEventSlim();
var starting = new ManualResetEventSlim();
AssemblyLoadContext.Default.Unloading += ctx =>
{
System.Console.WriteLine("Unloding fired");
starting.Set();
System.Console.WriteLine("Waiting for completion");
ended.Wait();
};
System.Console.WriteLine("Waiting for signals");
starting.Wait();
System.Console.WriteLine("Received signal gracefully shutting down");
Thread.Sleep(5000);
ended.Set();
}
}
Id'like to develop a web services + web sockets server using dart but the problem is I can't ensure the server's high availability because of uncatched exceptions in isolates.
Of course, I have try-catched my main function, but this is not enough.
If an exception occurs in the then() part of a future, the server will crash.
Which means that ONE flawd request can put the server down.
I realize that this is an open issue but is there any way to acknoledge any crash WITHOUT crashing the VM so that the server can continue serving other requests ?
Thank you.
What I've done in the past is use the main isolate to launch a child isolate which hosts the actual web server. When you launch an isolate, you can pass in an "uncaught exception" handler to the child isolate (I also think you should be able to register one at the top-level as well, to prevent this particular issue, as referenced by the issue in the original question).
Example:
import 'dart:isolate';
void main() {
// Spawn a child isolate
spawnFunction(isolateMain, uncaughtExceptionHandler);
}
void isolateMain() {
// this is the "real" entry point of your app
// setup http servers and listen etc...
}
bool uncaughtExceptionHandler(ex) {
// TODO: add logging!
// respawn a new child isolate.
spawnFunction(isolateMain, uncaughtException);
return true; // we've handled the uncaught exception
}
Chris Buckett gave you a good way to restart your server when it fails. However, you still don't want your server to go down.
The try-catch only works for synchronous code.
doSomething() {
try {
someSynchronousFunc();
someAsyncFunc().then(() => print('foo'));
} catch (e) {
// ...
}
}
When your async method completes or fails, it happens "long" after the program is done with the doSomething method.
When you write asynchronous code, it's generally a good idea to start a method by returning a future:
Future doSomething() {
return new Future(() {
// your code here.
var a = b + 5; // throws and is caught.
return someAsyncCall(); // Errors are forwarded if you return the Future directly.
});
}
This ensures that if you have code that throws, it catches them and the caller can then catchError() them.
If you write this way, you have much less crashes, assuming that you have some error handling at the top level at least.
Whenever you are calling a method that returns a Future, either return it directly (like shown above) or catchError() for it so that you are handling the possible errors locally.
There's a great lengthy article on the homepage that you should read.
In my MonoDroid application, when an unhandled exception occurs the application terminates without any messages. If I can reproduce the error on my local device I can debug it through Visual Studio without any problems.
However, on remote devices I am stuck for a solution.
I have tried the following in the Application class but it does not actually write my log file, unless I am running through the debugger in Visual Studio.
public override void OnCreate()
{
base.OnCreate();
AndroidEnvironment.UnhandledExceptionRaiser += new EventHandler<RaiseThrowableEventArgs>(AndroidEnvironment_UnhandledExceptionRaiser);
}
void AndroidEnvironment_UnhandledExceptionRaiser(object sender, RaiseThrowableEventArgs e)
{
// Write Log File
}
I disagree with #SpiritMachine's answer.
Mono documentation tells us:
Note: You cannot rely on the AppDomain.UnhandledException event as managed exceptions are never unhandled in MonoDroid; they are always intercepted at the Android/managed boundary within a catch(Exception) block.
Instead, I recommend that you do the following:
AndroidEnvironment.UnhandledExceptionRaiser += (sender, args) =>
{
// Do something...
};
Try something like this:
EDIT : This code cannot handle caught errors. Please see #Jim G.'s answer....
Personally, I would localise error handling to where you need it. The reason being, you don't know what your application state will be when this handler is recruited - you may be without resources that you're depending on to do the handling...
I'm developing an application using the Blackberry plugin for eclipse and I am getting the following error when making a call to a web service when I have deployed my application to a production server and handset... it works in my local simulator and development environment. (I can't hook my simulator directly to my production environment)
Uncaught exception: Application
app(150) is not responding; process
terminated
The call is being made from another thread.
The thread is passed to my CustomThreadManager to run
ClientChangeThread thread = new ClientChangeThread();
CustomThreadManager.Start(thread, true);
CustomThreadManager
ProgressPopup _progress = null;
if(showProgress){
_progress = new ProgressPopup("Loading...");
_progress.Open();
}
thread.start();
while (thread.isRunning())
{
try
{
CustomThread.sleep(300);
if(showProgress){
_progress.doPaint();
}
}
catch (InterruptedException e)
{
Dialog.alert("Error contacting webservice\n" + e.getMessage());
Functions.moveBack();
}
}
if(showProgress)
_progress.Close();
Some calls work while others dont.
The web service returns results fairly quickly so Im not sure if its the web service is too slow or problems with the threading.
Any help appreciated.
Thread.sleep() does not release any locks. This means your code to update the progress bar in the while-loop is holding the UI event lock, and prevents other UI updates from happening until the while loop terminates -- in this case when thread.isRunning() returns false.
You can use UiApplication.invokeLater(Runnable, long, boolean) to schedule a repeating UI update that will only hold the event lock while the Runnable is executing.