Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

URGENT Chat&: Max Monthly Usage Reached in 24hrs on Commercial Account?

Avatar

Level 2

So we're developing this enterprise LCCS app and the max concurrent connections error kept coming up, so I upgraded to the commercial account so we could more than have 5 sessions going. Which was fine, until a few days later, when I got this error:

LCCS_monthly_usage_limit_error_2011-08-30_01.jpg

So I thought, okay fine, I'll check the usage for the app, maybe I didn't assign enough money to the monthly limit. This is what the developer portal showed me:

LCCS_monthly_usage_limit_error_2011-08-30_02.jpg

I tried re-installing the Navigator SDK Viewer, thinking maybe I need a new one for a commercial account? The download is the same, and re-installing it didn't do anything. So I'm thinking it's a problem with my account?

How can I be over the monthly limit with 13 concurrent users, and under the moneys alocated to the app?

THIS IS A MAJOR PROBLEM. We are launching an alpha demo of this product within 48 hours, and all development has stopped, as hosts and users get booted out of rooms whenever this message pops up, and our software does not work reliably anymore.

Please help ASAP. You can reach me by phone at 705-352-1020 or by email at jbdesign@joeflash.ca

Thank you,

Joseph Balderson

Flex & Flash Platform Developer

http://joeflash.ca

32 Replies

Avatar

Level 2

Here's another weird thing it's doing now which it didn't used to. When the connections hold, and I don't get thrown out of rooms as previously described, this now comes up:

When the customer is logged into the CSR room, and the CSR removes the user from the room, the same login function used to logout and into other rooms is used to log the user back into the prelobby room. Except, now when the user logs back into the lobby, he is connected as a HOST, and not a Guest or VIEWER. This used to log in the use as guest in the prelobby just fine. Problem is, there are no developer credentials located anywhere in the code, so it should not be authenticating a guest as a host.

This causes the CSR app to not see the user logged into the prelobby, as it is designed to only show VIEWERs. The CSR app not seeing the user in and of itself is not a big deal, but logging in a user as HOST when it should be logged in as Guest/Viewer is a major security issue.

LCCS_monthly_usage_limit_error_2011-09-02_01.jpg

Notice that the user ID shown starts with "WCD" when it should start with "GUEST".

Here's the debug trace in Flash Builder for the customer app: http://is.gd/ywJlTV

And when the customer clicks the "ONLINE" image to log them into the lobby room, it logs them in as Guest just fine...

LCCS_monthly_usage_limit_error_2011-09-02_02.jpg

Notice the user ID now starts with "GUEST", as it should.

Here's the updated debug trace in Flash Builder for the customer app: http://is.gd/MFaBNl

Any idea why this might be happening? Like I said, squirrely connection behaviour.

If you could look into this ASAP after the weekend that would be greatly appreciated.

Thanks,

Joseph Balderson

Flex & Flash Platform Developer

http://joeflash.ca

Avatar

Former Community Member

HI Joe,

The ZOMBIE situation essentially means that 2 users are logging in with the same client ticket - meaning that they're identified as the same connection. In this case, when a new user logs in with that identical connection, the service thinks that it's redundant, and kicks out the original connection (usually, it means there's a client reconnecting, where the old connection is still hanging around).

  Are you reusing the same AdobeHSAuthenticator for multiple users (CSR, users, etc)? One way to try to untangle this is to try creating new AdobeHSAuthenticators for each user connection, and see if that improves things.

  nigel

Avatar

Former Community Member

Looking at the logs you sent (thanks, btw), it definitely looks as though you're using the same AdobeHSAuthenticator for the prelobby, lobby, and the custom room - this is where I'd start untangling it : Every time you want to start a connection, just spawn a new IConnectSession and AdobeHSAuthenticator.

  nigel

Avatar

Level 2

The customer app on the left is completely separate than the CSR app on the right. So the customer app logging back into the prelobby should not be triggering a Zombie Error in both Customer app AND the CSR app, as described above. And the Customer app logs in and out of rooms sequentially, there are no simultanteous connections. Nor should LCCS be promoting the user in the Customer app to HOST when no dev credentials are located in the customer app whatsoever, it simply should not happen.

As for the CSR app on the right, I thought it might be something like that, except... each room connection already uses a completely separate AdobeHSAuthenticator instance. So there should definitely be no Zombie errors.

        <rtc:AdobeHSAuthenticator id="plAuth" />
        <rtc:AdobeHSAuthenticator id="lobAuth" />
        <rtc:AdobeHSAuthenticator id="csrAuth" />

...

                plAuth.userName = AUTH_USER_NAME;
                plAuth.password = AUTH_PASSWORD;

...

                plSession = new ConnectSession();
                plSession.authenticator = plAuth;
                plSession.roomURL = LCCS_ROOMURL+ROOM_PRELOBBY;
...

[repeat for other two rooms]

And why would the room detect a zombie error and eject the CSR user, in the case described above, when the Room Console switches to the lobby? That makes absolutely no sense.

Methinks something is detecting duplicate authentications or handing out duplicate authentications where there should not be. Not to mention promoting users to HOST violating security protocols.

Thanks Nigel,

Joseph Balderson

Flex & Flash Platform Developer

http://joeflash.ca

Message was edited by: joeflashTO

Avatar

Former Community Member

Hi Joe,

Ok, if you could take this the next step I mentioned, it might help - each time you create a new session, also create a new Authenticator. You seem to be in some state where you're using cached credentials from old authenticators. So :

plAuth = new AdobeHSAuthenticator()

plAuth.userName = AUTH_USER_NAME;
plAuth.password = AUTH_PASSWORD;

plSession = new ConnectSession();

plSession.authenticator = plAuth;

plSession.roomURL = LCCS_ROOMURL+ROOM_PRELOBBY;

let us know if this helps

  nigel

Avatar

Level 2

So I did as you suggested: changed the MXML instantiation of AdobeHSAuthenticator to actionscript instantiation, to occur every time a new session is started. But it doesn't work. The exact same thing happened.

And I think I've nailed down the problem, because I finally have figured the predictability of the situation. Mostly. (But not the solution.)

So what I did was:

Process:

1a) I log in to the LCCS app with the Room Console. Then The Room Console user enters/logs into the prelobby.

1b) Then I log in with the CSR app (on the right), which creates all three AdobeHSAuthenticator instances, and connects to the prelobby and the lobby rooms simultaneously. Once both rooms connect the CSR's user name is changed from the developer default of "Daniel Lebor [n]" to the radio button option "jsmith" in both rooms. The session to the CSR room is started right after the user is connected to the lobby and the name changed to "jsmith".

(Originally the CSR app connected to all THREE rooms simultaneously, but in this latest version I deferred the CSR room login to see if it would make a difference.)

1c) After the prelobby and lobby connects but before the "csrjsmith" room session starts, the "monthly usage limit" error message pops up in the Room Console, and the Room Console user is kicked out of the prelobby.

Meanwhile, the Customer app (on the left) is not yet logged in.

LCCS_monthly_usage_limit_error_2011-09-08_01.jpg

2) When the Room Console user logs back into the prelobby room, it kicks the CSR user "jsmith" out, generating a Zombie error in the CSR app.

LCCS_monthly_usage_limit_error_2011-09-08_02.jpg

3) When the Room Console user leaves the prelobby and enters lobby room, it kicks the CSR user "jsmith" out of the lobby room, generating a Zombie error in the CSR app.

LCCS_monthly_usage_limit_error_2011-09-08_03.jpg


4) But when I have the Room Console user login/connect to the csrjsmith room, it succeeds, because they are logged in as "Daniel Lebor 2" thus there is no duplicate authentication.

LCCS_monthly_usage_limit_error_2011-09-08_04.jpg


5) But this causes other funky problems. From here, I log the CSR app out of all rooms, which calls ConnectSession.logout() for all rooms, and re-instantiates AdobeHSAuthenticator and ConnectSession instances for all rooms before starting the process over. But yet the CSR is still incorrectly logged into his csrjsmith room, creating duplicate credentials. As we see, merely checking the "Allow Duplicate User IDs" room setting does not solve the problem, it just allows the app to break in a different way.

LCCS_monthly_usage_limit_error_2011-09-08_05.jpg


6) If I try this experiment again, this time NOT re-entering any rooms with the Room Console once the "monthly usage limit" error has appeared, the app works just fine. The Customer user is able to log into the prelobby, the lobby and the CSR room sequentially without issues.

LCCS_monthly_usage_limit_error_2011-09-08_06.jpg


7) The Customer is even able to be logged out of the CSR room by the CSR app and log itself back into the prelobby, and the userID is as Guest, as it should be, and the illegal security promotion to HOST bug as described above does not occur. I can do this time and again, taking the Customer from prelobby to lobby to CSR room back to prelobby without incident... SO LONG AS I DO NOT USE THE ROOM CONSOLE TO ENTER A ROOM.

LCCS_monthly_usage_limit_error_2011-09-08_07.jpg

LCCS_monthly_usage_limit_error_2011-09-08_08.jpg


8) Your suggestion with the AdobeHSAuthenticator instances did make a slight difference in performance, actually. The Customer app used to get ejected with a Zombie error as well as the CSR user, whenever the Room Console would log in (sporadically, of course). But now the Customer user seems to stay logged in, and only the CSR user is expelled from the room with a Zombie error.

LCCS_monthly_usage_limit_error_2011-09-08_09.jpg


Conclusion:

What I think is happening is that under certain unknown conditions, the LCCS service is not recognizing that the CSR flex app needs to log in as "Daniel Lebor [n+1]". This used to work correctly, and now it does not, even with older versions of our alpha builds. For some reason LCCS authenticates the Flex app with the same credentials as the Room Console, so when the CSR logs into the prelobby room, it kicks the Room Console user out. But when the Room Console user tries to log back into the prelobby room, then the duplicate credentials cause a conflict and generate a Zombie Error in the Flex client, thus kicking the CSR user out of the prelobby room. I think the LCCS server is falaciously generating identical credentials for both the CSR flex app and the Room Console, and I think that the "monthly usage limit" error in the Room Console is this app's incorrect way of displaying a Zombie Error.
So we have two problems, as I see it:

1) the LCCS service is creating identical authentication/ticket/whateveryoucallit credentials between two or more apps, naming them both "Daniel Lebor [n]" instead of naming one as "Daniel Lebor [n]" and the other "Daniel Lebor [n+1]" (as it used to).

2) The Room Console is incorrectly displaying a Zombie Error resulting from a conflict in identical credentials as a "monthly usage limit" error.


Addendum:

1) However... sometimes I can log into all three rooms with multiple instances of the CSR app (logged in under different user names), but the moment I enter one of the rooms with the Room Console, say the prelobby, it not only ejects all the CSR users in the prelobby, but all the users in the lobby room as well, which makes ABSOLUTELY no sense.

LCCS_monthly_usage_limit_error_2011-09-08_10.jpg


2) The reason I think it may be something in the LCCS server authentication routines, is that this still comes up when the Room Console is not even running. The error message it shows may be incorrect, but the underlying issue is still present. If I log in with multiple CSRs (which used to work, BTW), even if I patiently wait till one is logged in before starting the next one, both prelobby and lobby rooms generate Zombie errors for most (but not always all) CSRs present in those rooms. The only time I have ever gotten a RTE in any of these tests is if I try and to login four CSR apps as fast as I can click [radio button]>Login... whcih gives me a "Error: UserManager.setUserStatus: insufficient permissions to change user name" error. But that only happens if I'm really trying hard to break the app.

LCCS_monthly_usage_limit_error_2011-09-08_11.jpg


3) The unpredictable thing is that sometimes, entering a room from the Room Console with Customers and CSRs already present, doesn't always eject the CSRs and/or Customers, as shown in previous screenshots. It's a mostly consistent bug, now that I understand it a little better. But every once and a while, everything works just fine, with different CSRs and the Room Console authenticating as "Daniel Lebor 1",2,3, etc. as it should... but mostly not.

Thanks for your help,

Joseph Balderson

Flex & Flash Platform Developer

http://joeflash.ca

Avatar

Level 2

So I tried modifying the CSR app so that it not only logged into each room session sequentially*, but instantiated the AdobeHSAuthenticator instances sequentially as well. Same results. As you can see from the screenshots, as each CSR app logs in, it ejects the CSR whom is already logged into the prelobby and lobby rooms. So the LCCS service is not creating new credentials for separate authenticator sessions. The debug trace I got from the app on the far left when it was kicked out was:

### CSR room session is: Connected. ###
    onCSRListChange: user Daniel Lebor has entered the room.
    onCSRListChange: user susyq has entered the room.
### prelobby session is: Disconnected. ###
    PreLobby Session ERROR = ZOMBIE: Another client with your same ticket connected. You need to disconnect.
### lobby Session is: Disconnected. ###
    Lobby Session ERROR = ZOMBIE: Another client with your same ticket connected. You need to disconnect.

LCCS_monthly_usage_limit_error_2011-09-08_12.jpg
LCCS_monthly_usage_limit_error_2011-09-08_13.jpg
LCCS_monthly_usage_limit_error_2011-09-08_14.jpg

*By "sequentially" I mean: SessionEvent.SYNCHRONIZATION_CHANGE event > if event.currentTarget.isSynchronized > connectToLobby(); > etc.
   
It's a problem if I can't run multiple Flex app instances under client-side dev login credentials on the same machine, or run the Room Console and a project app at the same time. I know we're not supposed to embed dev credentials in the code, we're supposed to use external authentication for session logins, and in fact we do have some Ruby script ready to go to handle external authentication, but if we can't get some simple tests working, until this is cleared up I don't even want to risk hooking it up and potentially opening up another can of worms, so to speak.

Help!

Thanks,

Joseph Balderson

Flex & Flash Platform Developer

http://joeflash.ca

Avatar

Former Community Member

Hi Joe,

Man, a bit of friendly advice on forums : I REALLY appreciate the effort you put into being as detailed as possible. BUT =), there comes a point when it's just too much too digest in one sitting. Any process of narrowing down what you perceive the problem to be would be very appreciated, because right now I feel I'm trying to drink from a firehose.

Anyhow, as to your post with points 1-8 (!! - and then conclusion 1-2, and addenda 1-3, confusingly), all of 1-7 are expected behavior if you've unchecked allowDuplicateUserIDs. From the docs : "Specifies whether the room allows users of the same userID to enter the  room. If set to false, a new user who enters the room with a  pre-existing userID    will eject the existing user with that userID".

What's happening is that when you log into a room as the developer (something that shouldn't be happening in a production environment), you're given a specific userID from the service. If you log in through the app as the developer, then log into the room console as a developer, you've just duplicated the userID, and the first of the users to log in is ejected.

You mention "As we see, merely checking the "Allow Duplicate User IDs" room setting  does not solve the problem, it just allows the app to break in a  different way.", but I don't really see.

For 8), the reason this is fixed now for the customer is that when you re-use AdobeHSAuthenticators, they cache previous user sessions, meaning that you stand a high chance of re-entering the room with a duplicate userID. Starting fresh will prevent this behavior.

So, I'll try to summarize my advice :

a) Don't mess with allowDuplicateUserIDs. Leave it checked. It's more than likely your issues all started when you started configuring rooms this way.

b) Start your sessions with fresh authenticators.

c) It's likely time for you to stop using developer credentials for the CSR. This is what's causing the dupicate userIDs between the CSR and the developer in the room console.

In reality, it's a) that's driving the majority of your issues. b) and c) are the vehicles that are causing duplicate userIDs, and triggering the behavior that a) is designed for (kicking old users out).

  hope that helps

   nigel

Avatar

Level 2

Thanks for your input, that helps.

Yes, setting the "Allow Duplicate User IDs" room setting does seems to have done the trick. Mostly.

But I have to say, I didn't quite believe it until I saw the duplicate UserIDs for myself.

LCCS_monthly_usage_limit_error_2011-09-10_01.jpg

I thought that because unique user names were being generated ("Daniel Lebor [n]"), that the UserIDs would necessarily be unique as well, which is why for the longest time I thought that the Zombie error must be a bug of some sort triggered by the weird Room Console error somehow.

What really threw me off is that your Room Console really does have a bug in it, but not what I thought it was: what it seems to be doing, as you hinted earlier, is interpreting a Zombie (i.e. duplicate UserID) Error as an "account limit" error. So I didn't actually clue into the "Allow Duplicate User IDs" flag until I figured out why the Room Console was generating that error. *sigh*

Now I understand that what I believed to be a bug is really a feature. What I don't understand is why it's a feature.

I am puzzled at a server authentication protocol which goes to all the trouble of generating a unique user name, but cannot produce a unique user ID, and generates an error if you disallow duplicate userIDs in the same room? In most server products where it's anticipated that duplicate authentication IDs may be generated by the same login credentials, the server would be capable of ensuring that session/user IDs are not duplicated. But in LCCS it's a given that they will be? That makes no sense to me.

Not messing with the "Allow Duplicate User IDs" room setting does solve our immediate problem, and I am glad the solution was something so simple. But it does not quite solve the overall issue.

The reason I had set that flag on those rooms is because every once and a while over the course of development the flash player would crash or I'd just simply close down the SWF without logging out first. The room would continue to behave as if the original user was still logged into the room, so when a user would re-enter one of the rooms, the user name would appear twice, messing up my room lists.

Q1a: Is there a way to differentiate between a cached/not-logged-in user and  present-and-logged-in user, both with the same UserID in the same room, so the old/cached one can be booted out?

Q1b: Is there an isLoggedIn flag or  something for the users listed in the UserManager collections? I don't see anything in the UserDescriptor.

Q2: Can a host remove another host with removeUser()?

Q3: Are User IDs duplicated using a server-side authentication as well, or does this happen only with client-authenticated apps?

Thanks,

Joseph Balderson
Flex & Flash Platform Developer
http://joeflash.ca

Message was edited by: joeflashTO

Message was edited by: joeflashTO

Avatar

Former Community Member

Hi Joe,

Re-read my previous post - Once you stop using developer authentication in

your app (a no-no to begin with), and use external authentication, you can

generate whatever userIDs you'd like. A developer has a fixed userID, which

you can't control, so you're seeing this as a result.

nigel

Avatar

Level 2

Hi Nigel,

I guess the point I was confused on is that the server-side script also uses the dev credentials to generate an authToken, but I guess on the server side it creates a unique "session" ID, whereas from the client-side it does not. (Request: PLEASE INCLUDE THIS FACT IN THE NEXT DOCS. This will save someone a lot of time.)

It really is a big help to hear that server-side authentication solves that problem.

Originally we were going to develop the whole CSR app client-side, and port over relevant authentication and room mgmt bits to the server when we went to alpha, but I see now we have to do a little more server side dev to get this working.

And also, your Room Console does still have a bug, BTW, even though it's merely mis-reporting an error.

Thanks very much for the feedback, this helps.

Cheers,

Joseph Balderson
Flex & Flash Platform Developer
http://joeflash.ca