Kjetil got hold of me today with a crash happening on the IBA server, everytime he clicked on a certain space in OFExplorer. On further testing, it turned out it was killing the server just logging into OFExplorer.
We re-wrote the token handling code some time back - to actually store the access tokens on the server, instead of sending them back to the client, and receiving them in each message. Some of them are huge - like ofiba for example - who has membership of lots of roles.
But for backward compatibility (I can't quite remember exactly why), we left the code in that sticks the tokens back in the outgoing message, possibly because older clients would expect to find them there. This code is removed from HEAD/head, so removed it from the scarab code on the IBA server, and whoppeee: it all works fine now.
The circumstances that lead to it rearing its ugly head seem to be related to the number of roles the current user is a member of, the ofiba user is a member of a lot. It was crashing because the SSL signature of the data in the AccessToken was far too long to be realistic., and it could've been caused by the length of the role list (perhaps.)
Thursday, November 23, 2006
Friday, November 17, 2006
Socket timeouts, keep-alives and buffer sizes
I've been trying to sort out the problems with the bubble upgrade, which we did some time back, using an export from the pyro server and an import into the scarab/wombat server. The export/import went fine, but we could replicatate any spaces from the new server afterwards.
I copied the old ofor files across to .9 and ran a new export. When we first tried this I needed to deal with the fact that the server certificate had been re-issued, so all the encrypted data in the repository could not be decrypted during the export. I got around this by allowing a secondary private key and passphrase to be supplied on the command line. This secondary key is automatically used if the first attempt at a decrypt fails. I also added a single-user function to go through and re-encrypt all data with the new key.
I cleaned the repository, built the applications, and created all the softrules as preparation for running the import. Then, just as a sanity test, I decided to try and connect to the server from a local VM, to see if my spaces would be replicated across locally.
As a combination of the low bandwidth and the network bouncing up and down, I kept getting timeouts whilst trying to replicate the softrules across to my local VM. After some more research and playing around, it seemed that the problem was happening because the client (local machine) has to hang around for quite a while whilst the server actually does what it needs to do to create its response to the request. Then the first couple of chunks are sent back to the client (which never seems to receive them) and the server times out.
I turned the SO_KEEPALIVE on for all sockets (in the OFSocket constructor), increased the send and receive buffer size (which didn't seem to do much anyway - not sure if Win32 allows this) and increased both send and receive timeouts. After this, the softrules and dictionary all diligently plodded across successfully.
Then, when I attempted a clean check the next morning, all the old problems resurfaced, so it seems I'm back to square one and more testing is required.
I copied the old ofor files across to .9 and ran a new export. When we first tried this I needed to deal with the fact that the server certificate had been re-issued, so all the encrypted data in the repository could not be decrypted during the export. I got around this by allowing a secondary private key and passphrase to be supplied on the command line. This secondary key is automatically used if the first attempt at a decrypt fails. I also added a single-user function to go through and re-encrypt all data with the new key.
I cleaned the repository, built the applications, and created all the softrules as preparation for running the import. Then, just as a sanity test, I decided to try and connect to the server from a local VM, to see if my spaces would be replicated across locally.
As a combination of the low bandwidth and the network bouncing up and down, I kept getting timeouts whilst trying to replicate the softrules across to my local VM. After some more research and playing around, it seemed that the problem was happening because the client (local machine) has to hang around for quite a while whilst the server actually does what it needs to do to create its response to the request. Then the first couple of chunks are sent back to the client (which never seems to receive them) and the server times out.
I turned the SO_KEEPALIVE on for all sockets (in the OFSocket constructor), increased the send and receive buffer size (which didn't seem to do much anyway - not sure if Win32 allows this) and increased both send and receive timeouts. After this, the softrules and dictionary all diligently plodded across successfully.
Then, when I attempted a clean check the next morning, all the old problems resurfaced, so it seems I'm back to square one and more testing is required.
Friday, November 10, 2006
Importer Licence
My new computer arrived - in Johannesburg, and I got a call from UPS ask me very politely to fax them a copy of my importer licence. Having no idea what one of these is, after several minutes of confused telephone chatter - I managed to determine what's required.
It seems that anything new imported into the country, over a certain value requires me (or whoever is doing the importing) to be registered as an importer.
Most of Thursday was then spent obtaining documents, affidavits, certified copies of identity documents, and substantial running around. The part where I handed over the application form (after filling it in three times,) to the people at SARS was actually very painless.
We now await with bated breath whilst the machine churns through its processes, and hopefully, within seven days, I will be an importer, and be able to get hold of my new machine - once I've paid the import duty on it.
The oddly placed sense of bliss once one has finished (successfully) dealing with red-tape and mindless bureaucracy....
It seems that anything new imported into the country, over a certain value requires me (or whoever is doing the importing) to be registered as an importer.
Most of Thursday was then spent obtaining documents, affidavits, certified copies of identity documents, and substantial running around. The part where I handed over the application form (after filling it in three times,) to the people at SARS was actually very painless.
We now await with bated breath whilst the machine churns through its processes, and hopefully, within seven days, I will be an importer, and be able to get hold of my new machine - once I've paid the import duty on it.
The oddly placed sense of bliss once one has finished (successfully) dealing with red-tape and mindless bureaucracy....
Tuesday, November 07, 2006
Halfdays and empty stomachs
Started the day well enough, and after fiddling around for a bit, got the transfer of the 12GB of Morgan backup data (rar'ed up to halve it in size) going across to the new portal server. We can FTP out from the new servers, so that did simplify things a bit.
Then, around lunch time things started to go pear shaped (unfortunate term) and I disappeared home at about half past three with my stomach doing some pretty impressive and hugely uncomfortable gyrations.
The next morning I discover that the network pinged down and up last night, and abort the FTP copy of the OFOR files, so I knocked up a very short Perl script to use wget to retrieve the final ones. This one was set running inside screen, so if anything goes wrong again with my network connection - it should still carry on. You'd think I'd have learned by now.
The rest of the day was spent very frustratingly trying to determine what was going on with Georgie's new machine, and the openFabric install on it. Whilst retrieving the softrules from her home server, packets from the server arrived with longer and longer periods between them. Eventually the delay would exceed the socket timeout value, and the request would fail.
The very odd thing about it is that I tried exactly the same thing from here, which is, networkalogically, much further away, and it ran through with no problems.
Then, around lunch time things started to go pear shaped (unfortunate term) and I disappeared home at about half past three with my stomach doing some pretty impressive and hugely uncomfortable gyrations.
The next morning I discover that the network pinged down and up last night, and abort the FTP copy of the OFOR files, so I knocked up a very short Perl script to use wget to retrieve the final ones. This one was set running inside screen, so if anything goes wrong again with my network connection - it should still carry on. You'd think I'd have learned by now.
The rest of the day was spent very frustratingly trying to determine what was going on with Georgie's new machine, and the openFabric install on it. Whilst retrieving the softrules from her home server, packets from the server arrived with longer and longer periods between them. Eventually the delay would exceed the socket timeout value, and the request would fail.
The very odd thing about it is that I tried exactly the same thing from here, which is, networkalogically, much further away, and it ran through with no problems.
Thursday, November 02, 2006
Retro-compiling
Spent most of the day trying to get the current source code for mchome to compile using current day compilers and libraries. The source dates back to around 5 years ago, and the current binaries run on a very out-dated SuSE 8.0 install (I don't think SuSE have officially support version 8.0 for yonks.)
After much fiddling, dealing with the fact that the source was upgraded to deal with 64 bit quite a bit since the mchome code was last touched, and the pernickityness of GCC 4.x (all good things I suppose) I finally got the code to build successfully. Now comes the interesting part - seeing if I can run the existing ofors on the newly compiled binaries.
After much fiddling, dealing with the fact that the source was upgraded to deal with 64 bit quite a bit since the mchome code was last touched, and the pernickityness of GCC 4.x (all good things I suppose) I finally got the code to build successfully. Now comes the interesting part - seeing if I can run the existing ofors on the newly compiled binaries.
Wednesday, November 01, 2006
The Sun and the Moon
Hacked out a bit of C code to determine the exact date and time that the Sun and Moon change their signs, for each year from 1925 right through to 2025.
Spent most of the time determining the best output format, which ended up being a plain text file, with one record per line, saved as a Word document for some reason. And then, lastly, discovered I had mis-spelt Sagittarius, so I had to re-run them all (after all that I realised I could simply have done a Find/Replace in the generated Word document - but there you go)
Spent most of the time determining the best output format, which ended up being a plain text file, with one record per line, saved as a Word document for some reason. And then, lastly, discovered I had mis-spelt Sagittarius, so I had to re-run them all (after all that I realised I could simply have done a Find/Replace in the generated Word document - but there you go)
Subscribe to:
Posts (Atom)
Posts
