If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Light streamer delete same user loggedin previously

In my case, I need to delete the session who logged in with the same credential in previously. It shouldn't allow keeping same user credentials to more than one user. So that I need to terminate the session if a new user logged in with same credentials. I need to serve only to the new user session.
I have tried in my metadata like below but I couldn't disconnect the previous session of the same user name.
private final ConcurrentHashMap<String, Map<String, String>> sessions = new ConcurrentHashMap<String, Map<String, String>>();
private final ConcurrentHashMap<String, String> userinfo = new ConcurrentHashMap<String, String>();

I see that you look for an existing session with the same user and, if found, you remove it from the "sessions" Map.
But this has no effect on Lightstreamer Server as the "sessions" Map is yours.
To have Lightstreamer Server close the previous session you should instead just throw a ConflictingSessionException, by specifying the previous session (that is, userinfo.get(user)) in its constructor.

At this stage, you shouldn't do anything else and leave the "sessions" and "userinfo" maps unchanged.
In practice, you will refuse the new session; but now you can expect immediately two more invocations from the Server:

the notifySessionClose of the previous session;

a second notifyNewSession for the new session.

This time, you will find no sessions for the user and you will be able to accept the new session.

For this to work, it is also important that, upon notifySessionClose, you can remove the involved user from the userInfo Map. Unfortunately, the user is not provided by the notifySessionClose invocation and it has to be inferred from the session ID.
It's not clear to me how you manage to do that; perhaps another Map is needed.

Hi, there was a misunderstanding.
When I suggested "you should instead just throw a ConflictingSessionException" and "At this stage, you shouldn't do anything else and leave the "sessions" and "userinfo" maps unchanged" I meant something like this:

The code you added seems unneeded.
The problem here is that we must agree on how the Server will invoke your Metadata Adapter.

When I said that "you should rely on the Server to call notifySessionClose and a new notifyNewSession to your Adapter", we were talking about what happens after you throw a ConflictingSessionException. So, I mean that you should expect the Server code to behave like this:

As you can see, if you throw a ConflictingSessionException, you will receive an invocation of notifySessionClose for the existing session to be closed and then a brand new invocation of notifyNewSession.

Moreover, you should never expect notifyNewSession to be invoked with a session ID already used, even in case of page refresh.

and focus now on notifySessionClose. How do you implement it currently?
As I said previously, you should ensure that it undoes exactly all that was done in notifyNewSession, which means removing the session line from both the "userinfo" and the "sessions" Map.

I have tried in all the way, but couldn't get the solution yet. Still the same session getting close when the page gets the refresh. The Same session also getting close. Please, could you help with some code?

Sorry but now I'm no longer sure I understood your goals correctly.
If a page is handling a session S1 and gets the refresh, then the new page tries to open a second session S2.
In this scenario, you can only manage to close S1 and let S2 succeed.
Are you trying to achieve somenthing different?

If you agree that S1 is the one that should be closed, then our suggestion is to keep two maps, in addition to the sessions map that you may need for your own purposes:

Then I see that your code examples involve further processing, like uniquelyIdentifyClient (which now I realize that you borrowed from our chat demo).
Note that I dodn't include them, as I don't know your requirements on those aspects.

Thanks for your reply.
This is working for me now. When I refresh the page it didn't get terminate the currently active session. But my goal is I have to terminate if any other session opened with my credential.(User Name is unique.) If anyone opened my application by using my credential in that time If I open my browser means my session only should be active and their session should get inactive and force their page to logout. Now I think It getting terminate the existing session.(I have checked in 2 browsers by using the same credential ). But I didn't get any response from Ls while getting terminate the session. If I get the session lost message means I could force the logout the page from the client side. Is it possible getting response while terminate the session.
I have tried in this way
lsClient.addListener({
onServerError: function(errorCode, errorMessage) {
//here you can consume the error
console.log("Connection Error: " + errorCode, errorMessage);
}
});

onSubscriptionError: function(errorCode, errorMessage) {
//here you can consume the error
console.log(errorMessage);
},
onCommandSecondLevelSubscriptionError:function(err orCode,errorMessage,relatedkey) {
//this one can only be fired in case a two-level subscription is created
//here you can consume the error
}

If you refresh the page, the old page should be destroyed before it can get the session close notification;
but if you open a new page on a different browser, the previous page is supposed to receive an invocation in onServerError, notifying error code 35.
It is strange that you didn't see anything.

We have to trace what happens.
Please reproduce the case on a dedicated Server instance, by opening only the two involved pages on two different browsers.
To keep the logs short, you should also prevent the pages from performing subscriptions, which are not relevant in this case.
As a first step, show us the Server log, taken after setting LightstreamerLogger.push at DEBUG level.