debian, apache2.4 and libapache2-svn

I did a stupid thing yesterday: I upgraded the apache of a development server running debian. Doesn’t sound too bad, does it? Did you know that the debian maintainers kinda dropped the libapache2-svn library when switching from apache2.2 to 2.4? No? Me neither :oogle: Why on earth did they do that? Well, asking this kind of question never helps, so I digged into it a little and tried to fix it without asking Google right away :/
So after a little research, I ran into a pretty good description that worked out. This stackoverflow post roughly explains what you have to do:

cd /tmp
mkdir svn_tmp
cd svn_tmp
sudo apt-get install apache2-dev
sudo apt-get build-dep subversion
apt-get source --compile subversion

Stop when it’s checking for gcc etc and edit some files:

Let’s edit some files. First, subversion-1.7.9/debian/control. Make sure that apache2-dev figures in Build-Depends sections (around line 7):

Build-Depends: debhelper, libneon27-gnutls-dev, libserf-dev (>= 1), zlib1g-dev,
               libapr1-dev, libaprutil1-dev, libdb5.1-dev,
               libsasl2-dev, apache2-dev,

Then, check if theres a section for libapache-2. If it’s there, make sure to remove the apache2.2-common dependency. If not, add the complete section:

Package: libapache2-svn
Section: httpd
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: db5.1-util
Description: Subversion server modules for Apache
 This package provides the mod_dav_svn and mod_authz_svn modules for
 the Apache 2.2 web server.  These modules provide Subversion's WebDAV
 server backend, to serve repositories over the http and https
 protocols.  See the 'subversion' package for more information.

Then, edit subversion-1.7.9/debian/rules and make sure that ENABLE_APACHE is true:

ENABLE_APACHE        := yes

Now, we are ready to start the build process again:

cd /tmp/svn_tmp/subversion-1.7.9 && dpkg-buildpackage -b -uc

This process may take a long time. For me, has taken like 1 hour. Finally, we can install the package.

sudo dpkg -i /tmp/svn_tmp/libapache2-svn_1.7.9-1+nmu3_amd64.deb 
sudo a2enmod dav_svn
sudo a2enmod authz_svn
sudo service apache2 restart

Android & Multithreaded HTTP-Requests

During the last 3 days on my new job at Sense Networks in New York I was supposed to fix some issues in a project concerning multi threaded http requests in an Android application. At first I thought it’d be a pretty easy task even though I never really used HttpConnectionManager before. So I started reading a bit about it and created some classes, interfaces and stuff like that to have a nice and generic architecture for the project. In fact I am using the MultiThreadedHttpConnectionManager (httpclient-3.x) but Android calls it ThreadSafeClientConnManager as it’s called in the httpclient-4.x which is currently in an alpha stadium.
After the first steps of implementing and testing the test application was throwing exceptions and I just couldn’t figure out why. It seemed to be totally random, the exception as well as the time it shows up. So I started reading tons of different tutorials for Android as well as for the Java2SE httpclient. No one seemed to experience the same problem and I admit it felt a bit like doing some basic newbie stuff wrong without knowing about it. After hours of research and testing the “bug” was finally found and it still seems to be pretty stupid but when you think about it, I’d say it isn’t that stupid. From my point of view it’s something that should be handled by the virtual machine, so for Android by Dalvik:
The response of a http request contains and entity which provides access to the content in form of an inputstream and this content has to be consumed otherwise it’ll never be removed from the memory even if you close/abort the request. Funny thing about this: I read ~50 pages, tutorials and threads but just one mentioned that in a comment line…
As all my tests were just sending a request to the given uri and then checking out the StatusLine for a possible error code the the response was closed if no error code was sent and “everything was fine”. At least that’s what I thought. In fact the sockets were still open, waiting for the empty content of the response to be consumed. So after some requests the memory was full and trying to open a new connection or sending a new request ended up in different exceptions (e.g. Timeout, Unknown Host, Connection refused). After figuring this out, the fix was quite easy. Now, before closing the response, the program consumes the content – even if it is empty – and then the vm cleans it up as expected. No more exceptions and everything works fine :)

By the way, you might want to check out CabSense ;)

To get notified about new posts, just enter your email address on the right :)