I am not sure how this is supposed to work though. From Amazon you get a private and public key after signing up for an AWS account. You use the public key in plain text as a parameter in your request. In addition you now (since August 2009 as it seems) have to add a timestamp and compute a signature key using the whole request string (including that timestamp and your public key) and the private key. Now append that signature as another parameter to the request and send it.

Of course every request will have a different signature because (a) you want to query for different stuff and (b) time changes and the timestamp must be recent or Amazon will consider the request as “old” and not worthy of an answer.

So what do you do now? Include your private key in your Python source, that you put out in a public repository? You probably shouldn’t, but that means the customer (user?) must have it’s own public/private key pair from Amazon. What a major inconvenience for the customer, to be required to have a AWS account just to get some covers.

Anyway, back to Listen. I created a branch of the 0.6 series on Launchpad  (a first for me, still getting used to bzr) and committed the necessary changes to amazon.py in revision 1126. Today I merged changes from the parent 0.6 and therefore that file now contains both public and private key — of someone else, not mine.

By the way, he original amazon.py is from of PyAWS. Unfortunately a later release of PyAWS 0.3 was not uploaded to SourceForge and further changes by others for the signature stuff also never found their way back to the repository. Isn’t open source great? </sarcasm>

The SQLAlchemy documentation says that with cx_Oracle >= 5 everything should just work, but earlier versions needed NLS_LANG set in the environment. Unfortunately they do not tell you anywhere near that paragraph that SQLALchemy <= 0.5.x needs it too. It took me another hour to find that information here. So set NLS_LANG to something like this and go selecting:

export NLS_LANG='AMERICAN_AMERICA.UTF8'

There is one trap however. Do not set ‘AL32UTF8′! Reading Oracle docs lead me to believe ‘UTF8′ or ‘AL32UTF8′ were valid values for NLS_LANG. They are not (so it seems) and setting them caused my app to crash with the following when connecting (which is not a very helpful message, if you do have ORACLE_HOME set properly):

sqlalchemy.exc.InterfaceError: (InterfaceError) Unable to acquire Oracle environment handle None None

More about valid values here.

Take a look at this… awesome!

This picture was generated from data collected from plain text logfiles inserted into MySQL using Perl, queried using Python/SQLAlchemy, served using a Python/WSGI application through SCGI using flup and Apache2 and plotted using JavaScript on Mozilla Firefox… and I get paid to do that!

gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -Dversion_info=(1,2,3,'gamma',1) -D__version__=1.2.3c1 -I/opt/mysql/mysql/include -I/opt/alcatel/logger/include/python2.6 -c _mysql.c -o build/temp.solaris-2.10-sun4u-2.6/_mysql.o -g -mt -m32 -xarch=sparc -DHAVE_RWLOCK_T -DUNIV_SOLARIS -DUNIV_SOLARIS
gcc: warning: `-x arch=sparc' after last input file has no effect
cc1: error: invalid option `t'
error: command 'gcc' failed with exit status 1

It happened to me on a Sun Fire V240 (sparc), but may also happen on i386.

The problem here is the “-mt” option. As mentioned in this forum post the “-mt” option is targeted at IA-64 platforms. This option is used because it is also used in MySQLs “–cflags” and setup.py uses mysql_config to determine build options. If you run mysql_config you probably get something like this:

# /opt/mysql/mysql/bin/mysql_config --cflags
-I/opt/mysql/mysql/include  -g -mt -m32 -xarch=sparc   -DHAVE_RWLOCK_T -DUNIV_SOLARIS -DUNIV_SOLARIS

To overcome this I added “m” to the compiler options to ignore in setup_posix.py in line 55:

removable_compile_args = [ compiler_flag(f) for f in "ILlm" ]

This makes it not use the “-mt -m32″ options from mysql_config. The “-m32″ option makes gcc generate code for 32-bit systems and regarding the “-x arch=sparc”: gcc ignores it anyway:

gcc: warning: `-x arch=sparc' after last input file has no effect

Furthermore there is a bug in the setup.py that seems to link dynamically even if you configure it to link statically in site.cfg. There is a patch attached to this ticket.

>>> os.path.abspath('/opt/stuff/things/bin')
'/opt/stuff/things/bin'
>>> os.path.abspath('stuff/things/bin')
'/opt/stuff/things/bin'
>>> os.path.basename('/opt/stuff/things/bin')
'bin'
>>> os.path.dirname('/opt/stuff/things/bin')
'/opt/stuff/things'

Here’s how you check out the code:

bzr checkout lp:exaile

There is a screenshot and the plugin package attached to this Exaile bug on launchpad.

So I set up Lighttpd as SCGI client and used flup to wrap a simple WSGI app in a threaded SCGI server. The configuration is pretty straight forward …

server.modules   += ( "mod_scgi" )
scgi.debug = 1

scgi.server = (
    "/" =>
    (
        "127.0.0.1" =>
        (
        "host" => "127.0.0.1",
        "port" => 4000,
        "check-local" => "disable",
        "disable-time" => 3
        )
    )
)

… and an example app using flup is also available online. I added a few lines to log the time the request arrived, a random time.sleep() and a log for after the sleep to simulate longer requests.

msg = "%s: %s: sleeping %s seconds, request %s" % (time.time(), thread.get_ident(), local, request)
time.sleep(random.randint(0,10))
msg = "%s\n%s: %s: slept for %s seconds!" % (msg, time.time(), thread.get_ident(), local)

The weirdness started when I actually tried to load the app in multiple tabs in Firefox at once. They were executed strictly one after the other. The start time stamp of the second tab was always about the finish time of the first and so on. Same effect with Chrome!

There is a forking and a threaded version of the flup SCGI server. I tried both. The thread.get_ident() output from my debug lines clearly showed that flup was multithreading. The serverside log of the SCGI/WSGI application however showed that the “GET /” requests did not come in all at once!

So I also set up Apache2 for the same SCGI server to see if Lighttpd was not working right. The configuration looked like this:

LoadModule scgi_module /usr/lib/apache2/modules/mod_scgi.so
SCGIMount / 127.0.0.1:4000

Again, the requests were processed strictly sequential.

Ok, so maybe SCGI just sucks. So I tried mod_wsgi with Apache2, but of course that showed the same behavior.

Finally, in a moment of desperation, I tested the app using IE8… and everything worked perfectly. All three start-timestamps were about the same. Now… what…?!

Firefox’s “network.http.max-connections” is set to it’s default value of 8. Don’t know about Chrome, but a Wireshark trace clearly showed that Firefox and Chrome send the “GET /” requests only after the previous one finished (using the same source port), while IE8 fires all of them at once (opening a new socket for each).

What is this!? Some weird “only one connection per server IP” rule? If anybody can shed some light on this, please comment!

Here are a few tips if you run into cryptic ORA errors and this is the official Python page in the Oracle Wiki.

If you use a connection pool — do not trust it! Network problems or simple timeouts can happen silently and the connections the pool manages could be gone even though the acquire() works just fine. I learned that the hard way… always got an “ORA-03135 – Connection lost contact” after around 15 minutes idle. Interestingly each third retry worked again. My minimum pool size was two, so the third connection would always be a newly opened one.

My workaround is now a loop around a connect() method…

success = False
for i in range(ORACLE_POOL_MIN+1):
    success = connect()
    if success: break
if not success: return

… and the connect() method has a short query to test the connection, before returning a success.

conn = oracle.pool.acquire()
cursor = conn.cursor()
cursor.execute("SELECT * FROM dual")