|
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.
|
|
|
|
|
That would be ok for simple web sites, who cares there to refresh several times. _Never_ applicable in a production environement.
Only my 2 cents.
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.
|
|
|
|
|
honey the codewitch wrote: Right now I'm thinking if it's paused it should, and if it's stopped it shouldn't.
At a minimum you need an easy way to flush messages without using the service if it defaults to retrying on startup. If not, it only takes one message triggering a crash bug early enough in the processing to trigger a DOS fault otherwise. "Early enough" is defined as "before anything in the service can decrement a retry count/etc to prevent this from happening".
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
It depends on what the service does and on what each message is.
|
|
|
|
|
Due to the Covid situation, some have suggested that you should not be allowed to walk around with an infectious disease. Seems reasonable. However, there have always been and there always will be infectious diseases (I presume) so what is the answer? And 99% of the time we carry such a disease we don't even know it.
Do we make masks in public required forever? No more handshakes ever again? (Sports athletes will have to get much more creative). Social distance forever? Lysol everything? (Might have to buy their stock.)
Our company is not enforcing masks. Is yours? How do you deal/cope with it? No big deal? Uncomfortable? I see so many people wearing masks even when they are alone that I think they have become a fashionable item.
Just curious if people think any of these changes will or even should become the normal forever.
My opinion is that none of these things should become the normal. I could do away with the handshakes, that would be fine. Most people are just fist bumping now anyway. But I definitely do not want masks forever (can't hardly breathe in them and the world misses out on my handsomeness). Social distancing I could live with since I was already practicing that anyway, but as a norm I still think would be silly.
Thoughts?
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.
|
|
|
|
|
As in introvert I feel like I've been training my whole life for this moment.
Stay out of my bubble!
Real programmers use butterflies
|
|
|
|