I found what was the issue.

There was indeed something happening in the audit portal. Each attempt of the page was adding a line in this page :

I added the role of the application /terminalsocket to %All and now the error is gone. I have no clue why this happened though, your package didn't seems to change this kind of parameters (Or maybe I missed it).

In any case, thank you for your help !

I tried these operations.

There was no /terminalsocket indeed in the web session portal before I launched a new session. However, this session does not disappear when I close the page. It even create another session for each attempt it make, so every 10 seconds. After waiting a bit (like 5 - 10 minutes), some begin to disapear.

It doesn't show more than the error message saying it can't connect, but it seems it use the 4.9.5 version, I found this in the index.js source file :

I notice the user is UnknownUser. Could this have an impact ?

Sorry for the late response, I didn't saw the notification.

Unfortunatly, the update didn't solve the problem. Is there a something particular I need to do beside importing the new package (still in the user namespace ?) ?

We actually are short on memory   So this might not be a solution for us.

I guess we're gonna wait for this new version while investigating further in the network protection then.

Thanks for the insights !

There might be something happening here indeed :

I'm not sure about the difference between local and distributed, but if seems like it exceed the maximum units authorized in the distributed part. Could that be the problem ?

If it is, how can we solve that, granted that before the update, the problem wasn't here ? I assume there might be some licence management we can do in this case.

So far I don't think our license is consumed since we can still use the entire product without any limitation. Or did I missunderstand the meaning of "license to be consumed" ?

Also, we're not using Docker version of Intersystems. And the two environments I mentionned are on the same machine. So there is two instances of Iris running on a windows server.

Indeed, I also compared these two, and they are identical.

However, I noticed this file : web.config appeared at the root of CSP folders. It seems to contain no settings whatsoever since there is only this in it :

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
</configuration>

This is the only difference I found so far between the two environments.

Also, maybe I should precise that the 2 environments are on the same server, so two instances of Iris runnning at the same time on the same machine (same version of course). Since one of them still works, I assume it is an Intersystems setting issue.

Thanks for the suggestion, I opened an issue on there Github.

Yes, I can confirm that I use this kind of url. It doesn't work with either of these : 

• Apache like this : fxhfgsevfapp57:56773/terminal/
• HTTP like this : this.is.url.com:56773/terminal/
• HTTPS like this : this.is.url.com/terminal/