1
00:00:01,650 --> 00:00:06,370
In the last video we did a little bit of debugging to figure out why some messages went missing and

2
00:00:06,370 --> 00:00:09,720
we eventually realized that there was a period of time after we killed a listener.

3
00:00:09,730 --> 00:00:13,720
During this restart process inside of our terminal we're in that streaming server thought that that

4
00:00:13,720 --> 00:00:15,720
client still might be active.

5
00:00:15,790 --> 00:00:19,140
So we spoke about one way to help Nats figure out that the client wasn't active.

6
00:00:19,150 --> 00:00:23,800
We could adjust those heartbeat values in this video we're gonna take a look at the other way of helping

7
00:00:23,800 --> 00:00:28,300
at Natsumi server understand that a closed client really is closed and that it should not try to send

8
00:00:28,300 --> 00:00:29,590
out any more messages.

9
00:00:30,060 --> 00:00:35,650
So to do so we're gonna add some code into our listener and our publisher inside this code that we're

10
00:00:35,650 --> 00:00:36,390
gonna write out.

11
00:00:36,490 --> 00:00:41,440
We're going to add in some code to detect any time that our listener or publisher programs are about

12
00:00:41,440 --> 00:00:43,290
to be closed down.

13
00:00:43,300 --> 00:00:47,320
And as soon as we detect that they're about to be closed down we're then going to intercept that and

14
00:00:47,320 --> 00:00:53,070
we're going to try to tell our Stan clients or our Nat's client that it needs to send a server a shutdown

15
00:00:53,140 --> 00:00:57,470
request and tell it hey just so you know I'm going off line consider me off line.

16
00:00:57,490 --> 00:01:03,600
Don't try to send me any more events so here's what we're gonna do inside of Stan on connect.

17
00:01:03,620 --> 00:01:06,110
We're going to first set up a little event handler.

18
00:01:06,110 --> 00:01:10,110
We're going to stay inside of your stand on close.

19
00:01:10,430 --> 00:01:16,310
So any single time or any time that we tried to close this client or disconnect from the running server

20
00:01:16,790 --> 00:01:26,380
we're going to do a console log of Nats in action closed and then Amelie after that we'll do a process

21
00:01:26,470 --> 00:01:34,780
dot exits which is going to just kick us out and say this process don't do anything else then down at

22
00:01:34,780 --> 00:01:36,250
the very bottom to file.

23
00:01:36,580 --> 00:01:41,650
I'm going to add in two handlers to watch for any single time that someone tries to close down this

24
00:01:41,650 --> 00:01:43,070
process.

25
00:01:43,090 --> 00:01:47,140
So an example of closing this down would be if we select this window right here and did a control C

26
00:01:47,470 --> 00:01:53,390
or whenever we manually restarted it using the Yes No dev tool we're gonna write inside of your process

27
00:01:53,400 --> 00:01:57,340
dot on this autocomplete is really annoying.

28
00:01:57,420 --> 00:02:05,240
Process not on sig int whenever that occurs we're going to run stand up close and we'll do something

29
00:02:05,240 --> 00:02:07,700
very similar for Sig term

30
00:02:13,670 --> 00:02:17,100
so these are watching for interrupt signals or terminate signals.

31
00:02:17,100 --> 00:02:19,110
These are signals that are sent to this process.

32
00:02:19,170 --> 00:02:24,930
Time that the test no Dev tries to restart our program or any time you hit control C at your terminal

33
00:02:25,770 --> 00:02:31,050
so we're going to intercept those interrupt or terminate requests to our program whenever that happens

34
00:02:31,050 --> 00:02:33,580
we're going to try to close down our client first.

35
00:02:33,650 --> 00:02:35,550
So we're saying Hey don't kill us just yet.

36
00:02:35,580 --> 00:02:39,580
I need to close my connection by calling Stan close.

37
00:02:39,600 --> 00:02:44,110
Our client is going to reach out to the node not server say don't see me any more messages that's going

38
00:02:44,110 --> 00:02:48,030
to cause our client to successfully or hopefully successfully close down.

39
00:02:48,150 --> 00:02:54,060
And then after it closes down it's then going to do the console log and then manually exit our program

40
00:02:54,060 --> 00:02:55,770
entirely.

41
00:02:55,840 --> 00:03:02,380
Let's say this I'll then go back over to my terminal.

42
00:03:02,450 --> 00:03:04,490
Looks like I don't have any errors over here from the get go.

43
00:03:04,520 --> 00:03:05,600
That's good.

44
00:03:05,600 --> 00:03:08,580
I'm not going to go back over to my monitoring window.

45
00:03:08,600 --> 00:03:14,130
I'm gonna refresh and I'm just gonna wait for a second or my list of subscriptions to go down to 2.

46
00:03:14,180 --> 00:03:20,030
So right now we don't we have not close that last instance when we just saved our code when we saved

47
00:03:20,030 --> 00:03:20,420
our code.

48
00:03:20,420 --> 00:03:25,500
We were closing down a copy of our program that did not have this extra stand close call inside of it.

49
00:03:25,610 --> 00:03:27,620
So I'm just gonna wait about 20 seconds or so.

50
00:03:27,620 --> 00:03:28,220
There we go.

51
00:03:28,220 --> 00:03:30,370
I'm now down to two subscriptions.

52
00:03:30,410 --> 00:03:36,140
Now in theory if I go back over to my terminal and I restart one of those listeners I should then be

53
00:03:36,140 --> 00:03:42,050
able to come back over to this window refresh almost immediately and still only see two subscriptions

54
00:03:42,560 --> 00:03:47,420
because the program that I just closed down should have reached out to at Nordstrom server until it

55
00:03:47,840 --> 00:03:48,770
closed me down.

56
00:03:48,860 --> 00:03:50,570
I don't exist anymore.

57
00:03:50,630 --> 00:03:52,950
I'm gonna flip back over to my terminal.

58
00:03:53,090 --> 00:03:58,250
I'm going to restart one of listeners and then very quickly go back to the browser refresh the page

59
00:03:58,760 --> 00:04:01,400
and I'll only see the two subscriptions.

60
00:04:01,550 --> 00:04:03,910
Perfect.

61
00:04:04,020 --> 00:04:09,150
So now I should not suffer again from that problem of having some missing messages.

62
00:04:09,240 --> 00:04:10,950
Now this is not a hundred percent.

63
00:04:10,950 --> 00:04:17,010
Having said that we're only going to attempt to close down that client if you receive one of these two

64
00:04:17,010 --> 00:04:18,610
interrupt messages right here.

65
00:04:18,690 --> 00:04:24,570
If you were on Windows Windows does not always use the same kind of SIG in Sig term.

66
00:04:24,570 --> 00:04:27,060
So if you're on Windows this might not work correctly.

67
00:04:27,060 --> 00:04:33,270
In addition if we forcibly kill this process if we say just wipe this process out then these handlers

68
00:04:33,270 --> 00:04:35,730
right here are not going to have a chance to run.

69
00:04:35,850 --> 00:04:42,960
For example if I open up my activity monitor on Mac OS I'm going to find the instances of no J.S. that

70
00:04:42,960 --> 00:04:44,530
I'm running.

71
00:04:44,640 --> 00:04:45,750
Here they are right here.

72
00:04:46,740 --> 00:04:48,940
And I'm going to hopefully kill the right one.

73
00:04:48,940 --> 00:04:55,380
Let me pull up my terminal and I'm gonna try to kill the one that is running one of my listeners and

74
00:04:55,380 --> 00:04:58,200
then immediately after that I'll go back with the browser repress the page.

75
00:04:58,200 --> 00:05:00,590
You're going to see that if I forcibly kill these things.

76
00:05:00,600 --> 00:05:05,170
Well that closed event does not actually occur or that close request doesn't occur.

77
00:05:05,250 --> 00:05:07,280
So let's see which of these is probably the right one.

78
00:05:07,290 --> 00:05:10,690
I don't know what does go randomly I'm gonna force quit the first one.

79
00:05:10,700 --> 00:05:17,900
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.

80
00:05:18,590 --> 00:05:19,290
There we go.

81
00:05:19,390 --> 00:05:23,090
Refresh and there we go I've now got three clients erroneously.

82
00:05:23,200 --> 00:05:27,400
One of these is actually dead and that's server just doesn't know it yet.

83
00:05:27,760 --> 00:05:32,710
It's all once again have to rely upon that heartbeat mechanism to make sure that MI server actually

84
00:05:32,710 --> 00:05:35,990
marksmen these things as offline.

85
00:05:36,010 --> 00:05:41,120
Now at this point I just want take a quick pause and say all this stuff probably seems like really crazy

86
00:05:41,120 --> 00:05:43,250
specific and way too in-depth.

87
00:05:43,280 --> 00:05:50,420
Well you got to keep in mind that very soon we're going to see that if one of these subscriptions is

88
00:05:50,480 --> 00:05:57,260
erroneously still alive like we saw Natsumi server is going to try to send it an event it's going to

89
00:05:57,260 --> 00:06:01,400
fail to be processed and eventually after 30 seconds Natsumi server is gonna turn and say okay Ms can

90
00:06:01,400 --> 00:06:04,290
take this event and send it to some other service.

91
00:06:04,310 --> 00:06:10,160
Well in that period of time in those 10 20 seconds 30 seconds however long it takes for mastering server

92
00:06:10,160 --> 00:06:13,330
to figure out that needs to take this event and send it somewhere else.

93
00:06:13,460 --> 00:06:18,080
There might have been other events issued and that's super interesting.

94
00:06:18,080 --> 00:06:23,630
Think about we might eventually have events in cyber application being processed in some not intended

95
00:06:23,690 --> 00:06:28,970
order because of all this subscription related stuff so that might not sound like a big deal just yet

96
00:06:29,180 --> 00:06:30,650
but let's take a quick pause right here.

97
00:06:30,650 --> 00:06:32,990
Come back next video I'll show you a couple of diagrams.

98
00:06:32,990 --> 00:06:39,290
Now do you understand how interesting things really gets if we have events arriving inside of our application

99
00:06:39,380 --> 00:06:41,150
outside of their intended order.