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.

Python backend afcs.py __roominstance None

Avatar

Level 3

Hello there, a little bit of backend digging for today

I am often getting this kind of errors:

Traceback (most recent call last):

File "/home/django/domains/edoboard.com/src/django/django/core/handlers/base.py",

line 92, in get_response

response = callback(request, *callback_args, **callback_kwargs)


File "/home/django/domains/edoboard.com/edoboard/edorado/AFCS_sessions/views.py"

line 75, in join_session

sess = am.getSession(afcsSession.key)


File "/home/django/domains/edoboard.com/lib/python2.5/site-packages/afcs.py"

line 375, in getSession

sess = session(self.__roomInstance, self.url.split("/")[-1], room)


File "/home/django/domains/edoboard.com/lib/python2.5/site-packages/afcs.py"

line 205, in __init__

self.__instance = instance.replace('#room#', room)


AttributeError: 'NoneType' object has no attribute 'replace'

instance happens to be null

> implying self.__roomInstance is null at line 375 is null.

> implying __initialize called in init or login does not set self.__roomInstance right:

l428


if response.tagName == 'meeting-info':

      (..)

      if len(response.getElementsByTagName("room")) > 0:

       self.__roomInstance = response.getElementsByTagName("room")[0].attributes['instance'].value

So it seems like no room tag was present or response.tagName was not 'meeting-info', too bad i do not log the raw response. I am not always able to reproduce this error.

Wondering if it could have anything to do with being 'thread safe' in Python.

In anycase if i get more of those i will start logging xml response.

If you have any ideas or startegies to share to catch this one, that would be great.

Greg

7 Replies

Avatar

Level 3

Just in case i installed Apache 2 prefork to see if it is tread related.

Avatar

Employee

It does feel that you are working with an "empty" accountmanager object, so it could be a thread issue (unless you have a clear case where you call am.getSession without calling am.login).

enabling the debug messages would help but I suspect we'll see the account manager initializer called twice.

Avatar

Level 3

Hello Raff,

I have got some news and you are not going to like it

I enforced apache prefork just in case but i was still getting errors time to time.

Then i activated the logging and refreshed my room every 10 seconds for a few times.

http://friendpaste.com/4K8NOm066ENfFHWdYfocrb

At one time a full html page is returned how strange is that ?

(I changed my user pass and added some ********* in keys just in case).

I use afcs.py rev 3

# Adobe Flash Collaboration Service Account Management API

#

# Revision

#   $Revision: #3 $ - $Date: 2009/02/04 $

The way i handle a room creation in python is as follow:

On request  http://www.edoboard.com/en/classes/test/

1. I create a unique room key for a user_guest on my backend.

2.

      am = afcs.accountmanager(settings.AFCS_ACCOUNT_URL)

      am.login(settings.AFCS_DEV_USER, settings.AFCS_DEV_PASSWORD)

      try:

           am.createRoom(roomkey, None)

      except Exception, inst:

           pass

    # get Session

    sess = am.getSession(roomkey)

    # get a token

    token = sess.getAuthenticationToken(settings.AFCS_SECRET, request.user.username, request.user.id, 100)

    roomURL = settings.AFCS_ACCOUNT_URL + "/" + roomkey

    return html with good token for the flex app.

Could it be that i am calling accountmanager too often ? Should i not instantiate it everytime ?

Thanks for your help !

Hope we can tackle this one.

Greg

Avatar

Employee

From what I see in the logs, one of the requests for getSession fails with an invalid authentication token (and the HTML page is the ConnectNow login page that has sneaked in because of a redirect when instead I should have returned an authentication error)

We have found a problem that may be the cause of this. The current authentication system, once in a while, is slow at propagating the authentication tokens between servers so what we think is happening is that you create the authentication token (for your account administrator) on one server and then try to validate on a different server (the one that ends up executing getSession) and if the token has not propagate yet you get the error.

We are working at getting this fixed but I don't have a time for this (a different person is working on this). One possible ugly fix is to wait between the time you authenticate and the time you call getSession (I was able to reproduce the problem but I didn't try this yet). The other is to catch the error and retry the full operation (create a new accountManager, login and call getSession).

I understand that none of these solutions is really clean but right now is all I can suggest. I will let you know as soon as we have a fix for this or a better solution.

One thing that I should probably do in the python script, that I have done in the ruby script, is to at least catch that I am getting an HTML page back when an XML response is expected and return an authentication error. At least you would know what's going on.

-- Raffaele (still Raff, but my forum id has magically changed on me )

Avatar

Employee

BTW, it turns out we deployed a fix for your problem just last night. I have run my test today and it's not failing anymore so please let us know if you see any other issue.

Avatar

Level 3

Great ! it's all good now.

Fast answer

Out of curiosity how did you fixed it on your side ?

server creating the token and getSession were force to be the same for a given request ?

Thanks

Greg

Avatar

Employee

No, this was really something related to how the authentication servers in our architecture replicate the information. I don't work on that particulat part of the system so I don't have all the details on this. For the more collaboration-specific servers we have a distributed shared memory that mantains all shared information, authenticated users included, but in this particular case the problem was between the login request, that goes straight to the authentication servers and the first request going through the collaboration servers.