Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[HELP] Keep getting error "The server has reached its maximum number of sessions."(BadTooManySessions)" #1534

Open
IhorYednak opened this issue Sep 24, 2024 · 3 comments
Assignees

Comments

@IhorYednak
Copy link

Describe the issue
I have 4 devices that linked to the same opcua IP, and 2 of them work, 2 of them doesn't
Once I check gateway connector logs - it gives me |ERROR| - [opcua_connector.py] - opcua_connector - __connect - 142 - "The server has reached its maximum number of sessions."(BadTooManySessions)"
I tried restarting the gateway - it's the same

I just want to make sure this is not the deal about the gateway itself.
Cuz I'm like 80% sure it's about the server where the opc-ua installed and buffering the data towards the gateway.

Also the IP is pingable

In the connector config files everything looks good
this is the connector file for one of the not working devices
{ "server": { "name": "OPC-UA Trumpf Proxy Server", "url": "192.168.248.21:11878", "timeoutInMillis": 5000, "scanPeriodInMillis": 5000, "disableSubscriptions":false, "subCheckPeriodInMillis": 1, "showMap": false, "security": "Basic256Sha256", "identity": { "type": "cert.PEM", "privateKey": "/etc/thingsboard-gateway/config/privatekey.pem", "cert": "/etc/thingsboard-gateway/config/certificate.der", "mode": "SignAndEncrypt" }, "mapping": [ { "deviceNodePattern": "Root\\.Objects\\.Laser 3", "deviceNamePattern": "Trumpf TruLaser (L81).A1221E0259", "attributes": [], "timeseries": [ { "key": "is_opcua_connected", "path": "${ns=1;s=OpcUaServers.Laser 3.ServerStatus}" },

Version of the gateway - 3.1.123
Thanks in advance!

@ashdam
Copy link
Contributor

ashdam commented Sep 25, 2024

In our company we have low number of sessions available so we got that error very frequently.
In previous versions, <= 3.5.1, sessions werent released after disconnecting actions such as "disabling" the gateway from TB server or taking GW container down.
Now, from 3.5.2 they have fixed that :)

@imbeacon
Copy link
Member

Hi @IhorYednak,

@ashdam is right. Earlier versions of the gateway uses default session timeout (1 hour), in version 3.5.2 - we have added force closing sessions(when it is possible), changed default timeout to 2 minutes and added ability to configure it by adding/changing sessionTimeoutInMillis parameter in server configuration.

@IhorYednak
Copy link
Author

IhorYednak commented Sep 26, 2024

Hi @imbeacon and @ashdam
Okay, thank you guys, I'll try updating it, and see how it goes, btw, do you have maybe a documentation on the update of the gateway? So that I will not mess up any configuration after the update.
Or is it just download and install over the already existing one and it's good to go?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants