|
So that explains Windows 10's upgrade process. 
|
|
|
|
|
My service framework has a message queue. That means there can be a backlog of messages. If the service gets stopped, like through the control panel, do you think it should execute that backlog when it gets restarted?
Right now I'm thinking if it's paused it should, and if it's stopped it shouldn't.
Is that intuitive, or is it just me?
Real programmers use butterflies
|
|
|
|
|
Make it a configurable option 
|
|
|
|
|
This project is already very difficult and confusing because I have to work around the service framework .NET gives you. I think that would just be spiteful to throw at the developer using this code. :P
And certainly no fun writing it. I did think about though. 
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: Right now I'm thinking if it's paused it should, and if it's stopped it shouldn't.
Sounds reasonable to me.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Depends on how important these messages are. In case they are only fire and forget who cares.
In case the receiver depends on all of them you need to make them "transactional safe" and forward them in case of pause or restart.
It does not solve my Problem, but it answers my question
Chemists have exactly one rule: there are only exceptions
modified 19-Jan-21 21:04pm.
|
|
|
|
|
That had occurred to me, but it's pretty difficult to handle in practice. I can do it, at the price of additional complexity but i take your point. Now that someone other than me wondered about it - just so much more the reason to consider it.
Real programmers use butterflies
|
|
|
|
|
Myself doing a lot of stuff writing services connected to third party system (among others SAP). All this mostly for production line systems where it is _very_ important not to loose any message (e.g. someting like "piece produced"). And yes this adds complexety and if I look to my code it is far away from nice 
It does not solve my Problem, but it answers my question
Chemists have exactly one rule: there are only exceptions
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Depends on what it is. ADT security systems do that. If you trip the alarm but there is no phone line it queues on the device. When a phone line is hooked up, even if it is 3 months later, the queue gets processed and the police get sent to your home.
WORST DESIGN EVER!!!
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Real programmers use butterflies
|
|
|
|
|
That's a real story. 
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
whoops!
Real programmers use butterflies
|
|
|
|
|
As someone who's had to stay at a friend's place a whole day to wait for and then watch an ADT guy install one of their systems - I found this funny, but I'm utterly not surprised.
If nothing else, it served to convince me to never pay for that garbage. Or maybe it was that particular guy. I can't remember the details. All I remember is the bad impression it left on me, over a decade ago.
|
|
|
|
|
It depends on the clients' expectations for a given message.
- Messages that must be processed within a given time ("time-critical") should be processed before the service is shut down or paused.
- Messages that must be processed, but not within a given time limit, ("TCP-style") should be processed before the service is shut down, but not before it is paused. When the service is un-paused, any messages in the queue should be processed.
- Messages that may be missed ("UDP-style") should be flushed from the message queue before shut down or pausing.
Processing time-critical messages, but not the intervening TCP-style messages, may lead to problems with the service's internal state, but then state machines are your expertise.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I'm actually using named pipes so far, and haven't done anything socketwise yet. Also there is no client. This is source code for other devs
Real programmers use butterflies
|
|
|
|
|
|
It depends upon the purpose of the service. Our automated build process runs as a service on our department servers. The process is essentially a finite state machine, and the build machine/service can be stopped and restarted at any state transition. When we first started with this version of the process, some of our builds took over 90 minutes. The ability to pause and cancel a build were important, especially with three servers sometimes each running multiple builds. We've stolen pilfered inventively acquired some better hardware for our servers, so most of our builds are down to 15 minutes or less. This has reduced the need for the pause/resume facility, but it's still nice to be able to restart a build server while a build is in progress, and the build still completes.
The only place where our approach has unexpected results is that the service implements a lightweight framework where we can perform product-specific actions as part of the process. If you change that code while a build using it is executing (easy to do while debugging), the results are... interesting. After doing this to myself several times, I modified the post-build step for the build service to delete existing build state.
Software Zen: delete this;
|
|
|
|
|
A camel is a horse designed by a committee. We just don't know if the committee was designing a very efficient machine for crossing the desert or something to run very fast.
In your case we don't know if the client needs a timely result, in that case it would be foolish not to check if the server is running or not ("buy me a ticket to yesterday's show" sounds like a silly request).
If your framework is something that's going to be used in different ways by different people you need to give them the option what to do in each case. Also give clients a way to find out what's going on.
Mircea
|
|
|
|
|
Man - restart the service and all queued messages have been forgotten.
Woman - restart the service and all queued messages continue to be delivered.
I suggest you create two services, one with an obvious male gender name, the other with an obvious female gender name. That would meet the criteria of "intuitive." 
|
|
|
|
|
Fred and Wilma
Real programmers use butterflies
|
|
|
|
|
Bonnie and Clyde? Beth and Jerry?
|
|
|
|
|
as others have said, 'it depends' (on what the service is doing) - I have worked with transactional or persistent messaging systems, where messages are backed to file for example - that would add another can of worms for you, although it could be an extensible 'option'
|
|
|
|
|
Possibly hot take but if logging is a "can of worms" you may want to reconsider your architecture.
|
|
|
|
|
I didnt mean it quite like it seems to have been taken, but in a lot of respects you're correct, there's no reason why persistent messages can't be logged to a seperate message file using standard logging constructs
|
|
|
|
|
If your service is stopped it shouldn't attempt to process outstanding messages. When you stop or start a service your service has a set time to respond, beyond that time the OS regards it as being out of control. If you processed outstanding messages when the service is stopped it could push you beyond the time your service has to stop. Beyond that it's semantically correct too; when I push the brake to stop my car I don't care what it is doing, I want to it stop now.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
