Session disconnecting

Hi all
Psi maintainer is here! :slight_smile:

@wroot, I don’t know why but only OpenFire users complaining about this problem and disabling SM on client side is always a solution.
Is it some problem with SM in OpenFire?

Could be. But also depends on a version of Openfire. There was a bug in SM in older versions.

I just installed 4.4.0 on localhost. Seems to work fine with SM.

Hi rion!

What is the SM and how may I disable it?
Thank you

You already marked this discussion as solved, so i’m puzzled. SM is short for stream management, which i believe you have already disabled.

Yeah, I have disabled it. I was just curious to know.
Thank you again (:

@wroot i know this thread has been closed but since i am facing the same issue posting it here rather then creating new thread.

I am facing the same issue i am using server version 4.4.1 and it showing me online on user page but on session summary there are nothing so what should i do as i am already on the latest version.

I was using openfire - 4.1.3 and every thing was fine but updated after checking lot’s of optimization but stuck here.

Anyway to resolve this issue i have disable the SM but i am not sure is it going to help or not i will check for next couple of days and update again.

Thanks.

If you have already disabled SM, i don’t have anything to add. Wait and see if this solves your issue. If not, open a new thread.

Issue still persists do i need to disable sm from both side i mean client and server ?

I have set a system property stream.management.active as false, Do i need to restart my server after setting this property ?

I don’t think restart is needed, but you can restart to be sure. As i’ve said, if you still get the issue, this is probably not related to SM and you should post a new thread, maybe provide logs.

I don’t think you have to disable it on the client side if server has it disabled.

created a new topic with providing crash logs.

thanks

I have set the stream.management.active false and apparently it is working fine, will observe it for a while

This will indeed disable the Stream Management functionality in Openfire. Note however that you’re responding to a pretty old discussion. Stream Management issues in Openfire have been resolved in the latest releases.

unfortunately, it is not resolved but the frequency of this error is decreased, we are on 4.1.6 version , do you know how to completely resolve this issue without updating the version?

Openfire 4.1.6 was released in October 2017, more than three and a half years ago. That’s even older than the first message of this discussion!

Although I have not checked for this specific version, it is very likely that the version has bugs with regards to Stream Management that have been fixed in later releases. It therefor might be impossible to use Stream Management, without updating - although I can’t be sure.

I strongly suggest that you consider an upgrade scenario. Apart from this functionality, other important changes have been introduced in later versions.

If you cannot move away from this particular version, you could consider reaching out to one of the companies that provide paid support for Openfire, to see to what extend it is feasible to backport stream management fixes to a project that is based on Openfire 4.1.6.

Thank you for your reply. the problem is that we have the openfire which acts as a backbone of our large scale product and at least 1000 concurrent users connected and sending and receiving real time messages extensively, we used the latest version in our another big application and the result was devastated and at the end they have to restore the backups and later switch to signalR. So, that’s why we are afraid to update the openfire version.

I’m sorry to hear that. It sound like you have some challenges in the way Openfire/XMPP was integrated in your systems. That might warrant further investigation.

The fact that you’re using it in a large scale product is all the more reason for your company to consider working on an upgrade strategy. You’re now using old software that has known defects. That can’t be good.

1 Like

Thanks for you help. I am planning to upgrade the version on our UAT environment first.

One more thing if you can help that our company ethical hacker write a macro in which he can send unlimited number of messages on xmpp in no time, it can affects openfire server and database. please note that it is a public chat in which we cannot implement captcha and cannot authenticate the user before start the chat. Could we do anything to prevent this, We also restrict the CORS with our domains.
Thank you in advance.

I think that we’re well beyond the scope of this particular discussion thread. Can you create a new thread please?

Yes, you are right, i just created here Chat Flooding Prevention a new topic. Could you please check