I have a WCF service which sends out commands to process some work at the handlers. Since I am doing this as a POC I have only one machine for handler and one for WCF. So my question is how can I make the Handler Executable run like 4 instances on the same machine(Like 4 threads at the same time).
To be more clear I want to run 4 parallel worker handlers on the same machine. Is there a setting while installing service or in configuration I can set this setting.
In v4 of NServiceBus you can configure the MaximumConcurrencyLevel, see http://docs.particular.net/nservicebus/msmqtransportconfig#nservicebus-v4-changes-to-msmqtransportconfig
Related
I've just learned how to use notifications and subscriptions in Chef to carry out actions such as restarting services if a config file is changed.
I am still learning chef so may just have not got to this section yet but I'd like to know how to do the actions conditionally.
Eg1 if I change a config file for my stand alone apache server I only want to restart the service if we are outside core business hours ie the current local time is between 6pm and 6am. If we are in core business hours I want the restart to happen but at a later time, outside core hours.
Eg2 if I change a config file for my load balanced apache server cluster I only want restart the service if a) the load balancer service status is "running" and b) all other nodes in the cluster have their apache service status as running ie I'm not taking down more than one node in the cluster at once.
I imagine we might need to put the action in a ruby block that either loops until the conditions are met or sets a flag or creates a scheduled task to execute later but I have no idea what to look for to learn how best to do this.
I guess this topic is kind of philosophical. For me, Chef should not have a specific state or logic beyond the current node and run. If I want to restart at a specific time, I would create a cron job with a conditional and just set the conditional with chef (Something like debian's /var/run/reboot-required). Then crond would trigger the reboot.
For your second example, the LB should have no issues to deal with a restarting apache backend and failover to another backend. Given that Chef runs regulary with something called "splay" the probability is very low that no backend is reachable. Even with only 2 backends. That said, reloading may be the better way.
I have written a service to host NServiceBus and for some reason NServiceBus is shutting down almost immediately after starting the service. If I run the executable manually everything works exactly as it should but as a service it decides to shutdown without an error being logged. Below is an example of the log files:
Selected active license from C:\ProgramData\ParticularSoftware\license.xml
Security warnings are reported due to opening up some of the security for testing purposes
Initiating shutdown.
Shutdown complete.
All of this takes place in 0.48 seconds.
This is a .net 4.6.1 application as my organization doesn't allow .net core at this point.
I have finally figured out the answer, I had 2 separate ways of closing the connection with NServiceBus, one was supposed to be used in the case that it was being ran as a console app, while the other was for when a service was running. The problem was that the one for the console app was also being hit by the service before it was supposed to, I have now resolved that issue.
I use Workbox to pre-cache assets required to render the app shell, including a basic version of index.html. Workbox assumes that index.html is available in cache, otherwise, page navigation fails because I have this registered in my Service Worker:
workbox.routing.registerNavigationRoute('/index.html');
I also have the self.skipWaiting() instruction in the install listener:
self.addEventListener('install', e => {
self.skipWaiting();
});
As I understand it, there are 2 install listeners now:
One that's registered by Workbox for pre-caching assets (including index.html)
One that I registered manually in my Service Worker
Is it possible for self.skipWaiting() to succeed while Workbox's install listener fails? This would lead to a problematic state where assets don't get pre-cached but the Service Worker is activated. Is such a scenario possible and should I protect against it?
I highly recommend "The Service Worker Lifecycle" as an authoritative source of information about the different stages of a service worker's installation and updating.
To summarize some info from that article, as it applies to your question:
The service worker first enters the installing phase, and however many install listeners you've registered, they will all get a chance to execute. As you suggest, Workbox creates its own install listener to handle precaching.
Only if every install listener completes without error will the service worker move on to the next stage, which might either be waiting (if there is already an open client using the previous version of the service worker) or activating (if there are no clients using the previous version of the service worker).
skipWaiting(), if you choose to use it, it will bypass the waiting stage regardless of whether or not there are any open clients using the previous version of the service worker.
Calling skipWaiting() will not accomplish anything if any of the install listeners failed, because the service worker will never leave the installing phase. It's basically a no-op.
The one thing that you should be careful about is using skipWaiting() when you are also using lazy-loading of versioned, precached assets. As the article warns:
Caution: skipWaiting() means that your new service worker is likely
controlling pages that were loaded with an older version. This means
some of your page's fetches will have been handled by your old service
worker, but your new service worker will be handling subsequent
fetches. If this might break things, don't use skipWaiting().
Because lazy-loading precached, versioned assets is a much more common thing to do in 2018, Workbox does not call skipWaiting() for you by default. It's up to you to opt-in to using it.
I want to use the spring state machine as the main processor of my application. I want to start the application, do the bootstrapping as an action of the initial state and tear down as an action of the end state. In the middle the application should wait for events.
So, I started by doing as shown in
http://docs.spring.io/spring-statemachine/docs/current/reference/html/developing-your-first-spring-statemachine-application.html
Everything works as described except that after exiting the run method the entire application stops and does not listen to further events.
How can this behavior be achieved? Is there a blueprint/template available? I didn't found one. Similar to a web component, listening for request, I want the state machine to wait for configured events. My application runs on a Raspberry Pi and those events are triggered by external actions like "button pressed", "a connected device delivers a measurement result".
Next to my main question I asked myself, whether spring state mechanine will work correct in my environment: I use Pi4J for hardware interaction. This framework usually uses its own threads for watching for hardware events. How will concurrent events be treated. Are actions always run synchroniously in the thread triggering the event or is there a separate thread pool?
Thanks,
Steve
This is a normal spring boot question as app will exit if nothing is keeping it alive. With boot apps you usually have a web layer and a thread from there keeps app alive.
statemachine docs have more info on how to configure executor to be threaded. On default execution happens in a same thread.
Pi4J is a good question as I'm not that familiar with its threading. I know that many bugs has been fixed as it used to create a lot of threads user didn't have no control and it's probably still a case. There's been some development on Pi4J to allow user to define thread factories which in theory could also passed to Spring TaskExecutor used by statemachine.
I have a GUI application that is used to configure a windows service and I want to start, stop or restart this service from thing GUI application.
One of the problems is that this service can run in two modes: windows service or manually from command line (so you have a console).
Now, I am looking for a way to communicate this, a way that would work in both cases.
It may be helpfull to specify that the service process already has and even handler that is dealing with:
CTRL_C_EVENT
CTRL_CLOSE_EVENT
CTRL_BREAK_EVENT
CTRL_LOGOFF_EVENT
CTRL_SHUTDOWN_EVENT
It would be quite easy to extend the handler if I knew what event will be triggered by the service restart option. Still, I should be able to trigger the same event from my GUI application so I will be able to tell the "server" to restart itself even if it is running in background.
The best is would be if I could do this without having to detect in which mode the server application is running.
There are Service Trigger Events that your service can listen for, and then your GUI can send an event. In particular, you want to register for an SERVICE_TRIGGER_TYPE_CUSTOM trigger, which causes your service to listen for an ETW event; your GUI code would then write the ETW event to trigger the event.
There is no service restart action. All you would do is stop the service normally, then start the service normally afterwards. That is all the SCM restart does internally, it is just exposed as a single operation in the SCM UI instead of as two separate options.