I'm taking a look at the listener test file.
Back inside of our Nats test project you'll recall that inside of here we said that anytime that our
process was about to be stopped either by an interrupt signal or a terminate signal we tried to close
down our client gracefully so we would call stand out close.
The client would then attempt to close.
Once it did close it would he met the closed event.
So we captured that closed event.
We said OK the thing has been cleaned up successfully.
And then we actually exited our process.
So we're gonna do something very similar back inside of our ticketing project as well so let me first
tell you one way that we could implement this.
This is not the good way to do it it's not the right way.
I just want to point out some issues and I'm going to show it to you because this might be something
you would do on your own.
I'm going to take stand out on closed right here.
I'm going to copy it.
Go back over to Nats wrapper.
I'm gonna find the Connect function and then right after that I'm going to paste in that stand out on
close.
I do have to change stand to this dot underscore a client of course.
I'm also gonna go back to listener.
I'm gonna take the to process dot on statements at the bottom copy those look back over it and that's
wrapper and paste them right underneath and then once again I'll update stand to this dot underscore
client and I go to put a exclamation or ultimately you know we could just do this dot client be a better
way of doing this.
OK so this right here would definitely work.
This would make sure that after we connect we then attempt to capture any closed event.
And once we capture it we're going to make sure we do cuts logs say hey everything was shut down successfully
and then exit.
And we also set up two listeners on the process to make sure there's ever an interrupt or terminate.
We are going to go ahead and close everything down.
This would definitely work without a doubt.
But we do not want to do this.
The reason why is that we have some method inside of here that is buried inside of some class inside
of our project that can possibly cause our entire process to exit entirely.
We do not ever want to have some method inside of some hidden away file that is going to suddenly cause
the entire program to exit definitely bad design right here as we might write this file.
We might decide to say put it inside of our common module and then use it throughout all of our different
services.
We would then have some shared library that might cause our program to exit entirely.
Can you imagine what that would be like if Mongoose behave the same if Mongoose could just suddenly
arbitrarily decide to exit your entire program.
That would probably not be super ideal.
So rather than putting code like this hidden away inside of some method we only ever want to allow something
to exit our entire program from inside of some more central location such as our index t s file so rather
than trying to directly exits from inside of connect we're going to instead put together a little bit
of functionality that's going to allow us to see that the client is attempting to close and then we'll
do the actual exit command from inside of index start to yes.
So again this would work but not ideal.
So how are we going to fix this.
Well essentially we're just going to take the same code where we're going to write it out inside of
our index not test file.
I'm going to cut all that right there.
I'm then going to go back to index start to yes and then right after our connect statement I'm going
to paste all that stuff in so we do have to repair a couple of references.
I'm to make sure I update this to Nat's wrapper client and then I'll update this right here.
Both these this clients both them should now be at Nats wrapper not clients like so OK.
So this is much better.
So now instead of a very central location inside of our project we can see that there is a condition
under which we're going to exit our entire program.
It would be really nice if we could somehow integrate this into our class because right now.
Well you know this is some very repetitive logic right here that we're probably going to want to duplicate
between our different services.
But again it just would not be a great form to hide this way inside of some far away file.
So this is now the big question here is how do we actually test this stuff and make sure it's working
as expected.
Well let me show you how we can test this very easily.
The first thing we're going to do is go back over to our terminal and we are going to re start scaffold.
Now it's really important that you restart scaffold because if you don't you're going to run into some
really strange situation.
So I'm going to kill scaffold.
I'm gonna see everything deleted.
I'm going to give those pods just a moment.
To get cleaned up.
So looks like they're all getting terminated.
Yep.
Good enough.
I'll go ahead and then restart scaffold
so it's going to take a second for everything to come back online
while that is all booting up.
There's my connected to that's right there by the way.
There's my connect connected to mongo DV and listening on port three thousand cats everything is now
refreshed all running.
Let's now try to simulate scarf or sweep.
We're gonna try to simulate gnats going down we're gonna try to just delete the Nats pod entirely.
That is going to cause the client to emit its own close event.
So when that thing gets closed we should then see the process exit entirely so I going to go back to
my terminal.
I to find a new terminal window.
I'm gonna get a listing of all my pods.
I'm gonna find a pod running that's and then do a cube TTL delete pod and then put in the name of that
pod if I now go backwards.
The primary scaffold window I will see eventually a console log of Nats connection closed.
Perfect.
And then a couple seconds after that for you it might take several seconds might take all that to 30
seconds or a minute.
You should eventually see the container started back up so we did successfully kill the process inside
there by calling process exit so we exited the process behind the scenes.
The pod running our container saw that the primary process of our container exited the pod then automatically
decided to restart the container inside there.
So it restarted the container and that's why we are seeing brand new output right here.
From T.S. no def we can probably also confirm that the container inside that pod was restarted.
If we do another K or cube Seitel get pods and now we'll see that our ticket's deployment right there
has had one restart that restart is because we lost our connection to net's all right.
So I'd say this is looking pretty good.
We are going to exit our process entirely any time that we lose our connection to gnats.
That is definitely something we want.
We are also going to make sure that any time that we get this interrupt signal or terminate signal we're
going to close down the client manually as well.
This looks pretty great.
Let's take a pause right here.
We still also have to test and make sure that whenever we create a new ticket we published an event
as well.
So still a little bit of stuff for us to do.