License.Limit.Exceeded with 4x150 users licence andonly 300 real users

[mm_patrick]

As indicated by the ongoing discussion, this issue can have different causes -
can you describe your application a little bit? How many users are connecting?
What kind of license do you have?
Do you have server-side code? If yes, what is it doing?
On what OS are you running?
What's the exact version (e.g. 2.0.3 r68) you're using?

[iGx]

Hello RUND,

We are using fms 2.0.3 at the moment and have found some success with making
some changes to the config files. As noted earlier in the forum post we have
added <MaxConnectionThreads>20</MaxConnectionThreads> to our server.xml. Also,
we are finding it helpful to change the JSEngine setting in the application.xml
to a setting of 61440.

Hope that helps.

Regards,

Dean

[jamezw]

What kind of license do you have?
1000-40 stacked (2000-80)
What's the exact version (e.g. 2.0.3 r68) you're using?
2.0.2 AND 2.0.3 (revision unknown, but the problem happened on both updates)
On what OS are you running?
Win2K3 Standard
Do you have server-side code?
Yes
If yes, what is it doing?
A CHILD FM Server connects to a PARENT FM Server (on an internal LAN) and
subscribes to its live streams. External clients then connect to the CHILD
Servers and request these streams. We generally have ~1000 active connections
to a CHILD server at any given time. The clients generally connect and
disconnect frequently but we never exceed our license of 2000 simultaneous
connections or 80 Mbps bandwidth. The License.Limit.Exceeded usually starts
occurring within minutes. Any suggestions?

[RUNd]

@ patrick:
It's a multi-room, multi-server videochat system
How many users are connecting?
50-60 connections per server
What kind of license do you have?
When i first replied we used 1000-40.pro on each server (4xwin2k3 dual
processor), now we're back to 150.pro, we decided we were never gonna reach
1000 connections since our bandwidth consumption is too high for that.
Do you have server-side code? If yes, what is it doing?
Yes, authentication, ewallet system, chats, proxied so's between servers and
application instances.
On what OS are you running?
win2k3 server
What's the exact version (e.g. 2.0.3 r68) you're using?
2.0.3 r68
by the way: I am sorry, but I can not reply to your private messages,
because you're declining them.
and i'm sorry too, but now i'm now accepting them...

I allready did what iGx advised:
<MaxConnectionThreads>20</MaxConnectionThreads> in our server.xml. And I
changed the JSEngine setting in the application.xml to a setting of 61440. And
it all seemed to work, untill last night. Again the license limit on
connections :(

I'm getting pretty desperate now, the client even suggested calling in extra
fms help. I don't know about what mm/adobe can do for us, but any help is
appreciated!

[iGx]

Hello RUNd,

You can minimize the impact of this problem by changing the scope in the
application.xml to "inst". If each chatroom is an application instance fms will
create an fmscore.exe for each room. Therefore, if you encounter this problem
you only lose a room and not your entire fms service. When you have identified
a problem room go to the log file for that room and look at application.00.log.
The last entry will tell you what core PID is associated with the locked room.
Open your task manager on the fms server, selet processes and if Process ID is
not shown click VIEW/select columns and check Process ID. Once you can see the
fmscore.ext PID end the process using task manager. Shortly thereafter we find
that fms will correct the problem and restart the room with a new application
instance and core.

I have heard that someone has had success with fms 2.0.1 with this issue.
Although we had tried that in the past we are testing fms 2.0.1 with our
customized server config xml files and improved flash remoting. We hope will
show some results. I will post here if we have any success.

Regards,

iGx

[iGx]

Hello,

We have noted a bit of an interesting pattern with all the cores that are
associated with applications that seem to hang. When we view the admin logs we
find the following for a given core and its associated application instance.

-2006-11-15 11:06:04 17316 (i)2581241 Connection to admin received.
-2006-11-15 11:06:04 17316 (i)2581243 Connection from core 18756 received.
-2006-11-15 11:06:04 17316 (i)2581244 Connection from core 18756 accepted.
-2006-11-15 11:06:13 17316 (i)2581242 Core (18756) disconnected :
_defaultRoot_:_defaultVHost_:chat:room221.

However, our problem cores are logged as such:

-2006-11-15 12:37:16 4732 (i)2581241 Connection to admin received. -2006-11-15
12:37:16 4732 (i)2581243 Connection from core 5328 received. -2006-11-15
12:37:16 4732 (i)2581244 Connection from core 5328 accepted. -

* note: there is no disconnect for Core 5328

It is not until we manually remove the core using taskmanger after identifying
a problem wth the assocated application instance do we see the following
disconnect message that would typically follow a normal startup in the admin
log.

-2006-11-15 21:09:30 4732 (i)2581242 Core (5328) disconnected :
_defaultRoot_:_defaultVHost_:chat:room111.

Does anyone else see this type of break in pattern in their log file?

Thanks!

iGx

[iGx]

Hello,

Just wanted to leave an update for everyone to review. We tried going back to
fms 2.0.1 as some people have indicated they had success doing so. However, we
had the same problem after two days. An interesting note is that the
fmscore.exe that had been running for almost two days did not have th problem.
The a new core only 1 hr. 40 mins. old had a problem. Again we saw the same
pattern in the admin.00.log. This core did not have a disconnect as I have
previously talked about here.

In our situation I can say with certaintly that if a core starts and I do not
see this disconnect in our admin.00.log it will fail.

In our case the problem does not seem to be linked the lifetime of the core,
the frequency of connection request to the core or number of people connected
since we have seen widely varied values for these.

Thanks all for the help. Any feedback would be appreciated.

Regards,

iGx