In the last video we did a little bit of debugging to figure out why some messages went missing and
we eventually realized that there was a period of time after we killed a listener.
During this restart process inside of our terminal we're in that streaming server thought that that
client still might be active.
So we spoke about one way to help Nats figure out that the client wasn't active.
We could adjust those heartbeat values in this video we're gonna take a look at the other way of helping
at Natsumi server understand that a closed client really is closed and that it should not try to send
out any more messages.
So to do so we're gonna add some code into our listener and our publisher inside this code that we're
gonna write out.
We're going to add in some code to detect any time that our listener or publisher programs are about
to be closed down.
And as soon as we detect that they're about to be closed down we're then going to intercept that and
we're going to try to tell our Stan clients or our Nat's client that it needs to send a server a shutdown
request and tell it hey just so you know I'm going off line consider me off line.
Don't try to send me any more events so here's what we're gonna do inside of Stan on connect.
We're going to first set up a little event handler.
We're going to stay inside of your stand on close.
So any single time or any time that we tried to close this client or disconnect from the running server
we're going to do a console log of Nats in action closed and then Amelie after that we'll do a process
dot exits which is going to just kick us out and say this process don't do anything else then down at
the very bottom to file.
I'm going to add in two handlers to watch for any single time that someone tries to close down this
process.
So an example of closing this down would be if we select this window right here and did a control C
or whenever we manually restarted it using the Yes No dev tool we're gonna write inside of your process
dot on this autocomplete is really annoying.
Process not on sig int whenever that occurs we're going to run stand up close and we'll do something
very similar for Sig term
so these are watching for interrupt signals or terminate signals.
These are signals that are sent to this process.
Time that the test no Dev tries to restart our program or any time you hit control C at your terminal
so we're going to intercept those interrupt or terminate requests to our program whenever that happens
we're going to try to close down our client first.
So we're saying Hey don't kill us just yet.
I need to close my connection by calling Stan close.
Our client is going to reach out to the node not server say don't see me any more messages that's going
to cause our client to successfully or hopefully successfully close down.
And then after it closes down it's then going to do the console log and then manually exit our program
entirely.
Let's say this I'll then go back over to my terminal.
Looks like I don't have any errors over here from the get go.
That's good.
I'm not going to go back over to my monitoring window.
I'm gonna refresh and I'm just gonna wait for a second or my list of subscriptions to go down to 2.
So right now we don't we have not close that last instance when we just saved our code when we saved
our code.
We were closing down a copy of our program that did not have this extra stand close call inside of it.
So I'm just gonna wait about 20 seconds or so.
There we go.
I'm now down to two subscriptions.
Now in theory if I go back over to my terminal and I restart one of those listeners I should then be
able to come back over to this window refresh almost immediately and still only see two subscriptions
because the program that I just closed down should have reached out to at Nordstrom server until it
closed me down.
I don't exist anymore.
I'm gonna flip back over to my terminal.
I'm going to restart one of listeners and then very quickly go back to the browser refresh the page
and I'll only see the two subscriptions.
Perfect.
So now I should not suffer again from that problem of having some missing messages.
Now this is not a hundred percent.
Having said that we're only going to attempt to close down that client if you receive one of these two
interrupt messages right here.
If you were on Windows Windows does not always use the same kind of SIG in Sig term.
So if you're on Windows this might not work correctly.
In addition if we forcibly kill this process if we say just wipe this process out then these handlers
right here are not going to have a chance to run.
For example if I open up my activity monitor on Mac OS I'm going to find the instances of no J.S. that
I'm running.
Here they are right here.
And I'm going to hopefully kill the right one.
Let me pull up my terminal and I'm gonna try to kill the one that is running one of my listeners and
then immediately after that I'll go back with the browser repress the page.
You're going to see that if I forcibly kill these things.
Well that closed event does not actually occur or that close request doesn't occur.
So let's see which of these is probably the right one.
I don't know what does go randomly I'm gonna force quit the first one.
Oh I got lucky so I'm going to flip back a really quickly refresh and I've got to start up the new one.
There we go.
Refresh and there we go I've now got three clients erroneously.
One of these is actually dead and that's server just doesn't know it yet.
It's all once again have to rely upon that heartbeat mechanism to make sure that MI server actually
marksmen these things as offline.
Now at this point I just want take a quick pause and say all this stuff probably seems like really crazy
specific and way too in-depth.
Well you got to keep in mind that very soon we're going to see that if one of these subscriptions is
erroneously still alive like we saw Natsumi server is going to try to send it an event it's going to
fail to be processed and eventually after 30 seconds Natsumi server is gonna turn and say okay Ms can
take this event and send it to some other service.
Well in that period of time in those 10 20 seconds 30 seconds however long it takes for mastering server
to figure out that needs to take this event and send it somewhere else.
There might have been other events issued and that's super interesting.
Think about we might eventually have events in cyber application being processed in some not intended
order because of all this subscription related stuff so that might not sound like a big deal just yet
but let's take a quick pause right here.
Come back next video I'll show you a couple of diagrams.
Now do you understand how interesting things really gets if we have events arriving inside of our application
outside of their intended order.