Re: Issue with publicSID in memory based session cache

2013-01-31 Thread seba.wag...@gmail.com
I have made a few glitches because I was testing with the wrong branch. Should be better now. *Also I believe address is more human-readable value in config than serverId :)* => I believe the same. I will refactor the code to have the host in that variable instead of the serverId. Sebastian 201

Re: Issue with publicSID in memory based session cache

2013-01-31 Thread Maxim Solodovnik
Ok thanks! I'll retest today and will let you know On Fri, Feb 1, 2013 at 11:01 AM, seba.wag...@gmail.com < seba.wag...@gmail.com> wrote: > Maxim, > > you should be able to re-run your test. I have almost the same > implementation now again for the memory based session. > There might be a way of

Re: Issue with publicSID in memory based session cache

2013-01-31 Thread seba.wag...@gmail.com
Maxim, you should be able to re-run your test. I have almost the same implementation now again for the memory based session. There might be a way of performance increase to have a second map, with the "scope" as key: Map> clientsByScope or Map> clientsByScope (in this case the inner Map would have

Re: Issue with publicSID in memory based session cache

2013-01-31 Thread seba.wag...@gmail.com
... the roomId is also wrong by the way. You can see it by doing the following: Open two browser tabs and load openmeetings, go with one client in a conference room but _not_ choose any device settings yet and keep the device settings dialog open. Go with the second browser in the admin > UI > conn

Re: Issue with publicSID in memory based session cache

2013-01-31 Thread seba.wag...@gmail.com
Yes, I found out the root of the issue. The root is not the HashMap actually, the root is that we change the publicSID of the RTMP connection that connects to the SWF10 app dynamically. The SWF10 rtmp connection intially gets a publicSID assigned, but to makes sure the client has the same rights l

Re: Issue with publicSID in memory based session cache

2013-01-30 Thread Maxim Solodovnik
Here is the scenario to reproduce the weird behavior with publicSID: 1) login as user1 2) enter any room 3) do nothing, exit the room 4) repeat steps 2 and 3 5 times 5) open Administration->Connections Result:clientsByServerAndPublicSID Server null Number of PublicSIDs: *16 * * * I believe nu

Re: Issue with publicSID in memory based session cache

2013-01-30 Thread Maxim Solodovnik
Also I believe address is more human-readable value in config than serverId :) On Thu, Jan 31, 2013 at 12:47 PM, Maxim Solodovnik wrote: > The first issue was with > openmeetings-applicationContext.xml > > "null" in serverId was interpreted as String with value "null" (4 > characters) > > The se

Re: Issue with publicSID in memory based session cache

2013-01-30 Thread Maxim Solodovnik
The first issue was with openmeetings-applicationContext.xml "null" in serverId was interpreted as String with value "null" (4 characters) The second issue was with ManageCryptStyle, it was not autowired in anonymous class Was tested on 2 machines (Linux+Windows) continue investigating On Thu

Re: Issue with publicSID in memory based session cache

2013-01-30 Thread seba.wag...@gmail.com
Are you sure you are using the default config files and a fresh build? Cause I don't have those errors. It seems like your openmeetings-applicationContext.xml is outdated or you did not svn update. Sebastian 2013/1/31 Maxim Solodovnik > Currently OM is broken (on our side) > > Here is the part

Re: Issue with publicSID in memory based session cache

2013-01-30 Thread Maxim Solodovnik
Currently OM is broken (on our side) Here is the part of stacktrace from OM log: ERROR 01-31 12:09:40.339 ScopeApplicationAdapter.java 56269 199 org.apache.openmeetings.remote.red5.ScopeApplicationAdapter [http-nio-0.0.0.0-8088-exec-6] - roomJoin java.lang.NumberFormatException: For input string: