Month: May 2020

I mentioned on one of my past posts that I’d noticed that user criteria in ServiceNow don’t update in real time. The get checked the first time you try to look at something, and are cached at that point.

That can be problematic when you are updating a user criteria and you still seeing everything you’re not supposed to see (or not seeing something that you should be able to see) because the old version of the user criteria is still cached.

I ran into that same issue last week, and didn’t have the option of just waiting for the cache to be updated at some nebulous point in the future.

I did some looking, and found out that the cache is supposed to refresh when you log out of and then back into ServiceNow.

I tried that without any success, which meant that I was supposed to move on to clearing the cache to reset the user criteria in the user’s cache.

I knew that you could type cache.do in the filter navigator, but that only worked if you had certain rights, which the user I was supporting didn’t seem to have, so I seemed to be in a pickle.

The solution should have been much more obvious to me than it was. I just needed to use the url to trigger the cache.do call.

**service-now.com/nav_to.do?uri=%2Fcache.do

I’ve spent a week or so at this point working on a rendezvous problem based on my understanding of the course content from the Berkeley class that I mentioned in an earlier post.

I’ve got something that successfully streams, and successfully allows data to rendezvous, and successfully writes out the data at the end.

Small data sets that I can hand-check are working perfectly, but something is going wrong with larger data sets and I’m getting outputs saying that more numbers were processed than were in my data set.

It seems to be an issue with the code that writes the unmatched data from the hash table out to the unmatched data file. I’d like to continue working through it, but need to get back to the consulting work that has started stacking up, so I’m going to have to set this to one side.

However, I’m going to link to the code because I’m worried that if I don’t, that I’ll never post the result of so much time and effort.

A key takeaway for me on the project (in addition to all of the learning about how streams work in NodeJS), is that when all was said and done, it turns out that there is an “EventStream” npm module that would have probably cut a whole bunch of time out of my efforts.

I’m seeing a recurring theme in my development efforts where I end up trying to re-invent the wheel because I don’t know what resources are out there.

Some of that will probably improve through the simple passage of time, but part of my educational efforts in the future will include running through npm packages so that I in the future I’ll have an idea of what resources exist to speed my efforts up.

Also, here is a link to the post that pointed me towards the EventStream npm module:

https://itnext.io/using-node-js-to-read-really-really-large-files-pt-1-d2057fe76b33

As I was working on my self-assigned homework to write an algorithm that would stream data in, and then hold the data in memory waiting for a rendezvous to happen, I ran into an error that was new to me:

MaxListenersExceededWarning: Possible EventEmitter memory leak detected

Some research pointed me to the root cause of my issue. You should only ever define a given event listener a single time. That means you shouldn’t define an event listener in a loop, or in a function (since the function sooner or latter will end up being called more than once).

I suspect it’s more of a rookie mistake, which means it’s a little embarrassing to admit to, but if I hide my deficiencies, it just makes it that much harder to get better. Besides, maybe someone else making that ‘rookie’ mistake will stumble onto this and it will help them debug their code a bit faster than they would have managed otherwise.