log4cxx insights

i really liked log4cxx and while i did a thorough research, turned out there were a few things i hadn't realised log4cxx featured or was capable of

- hierarchy is awesome, i had used it with test cases like
log4j.logger.main=ERROR, console, file
log4j.logger.main.another=INFO

where`another` inherits console and file appenders from `main`

but i hadn't realised that if `another` featured, well, another console appender, then the log message would be displayed twice - once for the console appender from `main` and once from `another`

log4j.logger.main.another=INFO, console2

the way to avoid this is to tell log4cxx we don't want the child to inherit any appenders from the parent, like this -
log4j.additivity.main.another=false

it is actually quite evident from the quick tutorial on the log4cxx site, but i guess i kindda missed that


- different log levels for each appender - now i  really hadn't realised that log4cxx was capable of this: when you want console to print all messages, but file output would feature only errors
turns out this can be easilly done with

log4j.appender.console.Threshold=TRACE
log4j.appender.file.Threshold=ERROR

isn't this beautiful!!


there hasn't been official release for log4cxx for quite a few years which might be startling, but then this library is so awesome, i'd rather risk and use it in production then go for another one, or (no way) write a custom framework...

simple android service not starting

i'm new to android.
but it seems a nice platform so far.
been away from java for quite some time and find some syntax shortcuts are quite amazing but on the problem at hand;
i wanted to write a very simple test service and eventually settled for this scenario:
- start an activity
 - on button click the activity starts a service
- thats it!

and this gave me hours of grinding google and stackoverflow, because this very simple service never seemed to start

 one of the first issues was "newinstance failed no ()" that was quite easy to solve thanks to http://stackoverflow.com/questions/2120699/newinstance-failed-no-init. but then non of the debug loggers i put through out the code seemed to be fired i the service i had onCreate(), onStartCommand(), onStart() and none was ever triggered 
 i had big suspicions on the AndroidManifest.xml as it is still quite a blank area for me. startService() returned Null whatever i passed to it. 
my service was declared in the file that countained the activity so the name i tried to input as service android:name were like mainNamespace.Activityname.ServiceName, but this didn't work, nor did mainNamespace.ServiceName, not any of the other attempts 

 to save some hdd space on the blog host - i moved the code of the service outside the file containing the activity class, added new service name in the manifest xml and suddenly i started seeing the debug messages i waited to see for quite some time! 
 so what was i doing wrong? what should've been the name of the service in the manifest xml for the service class contained within the same file? or was it the naming in the Intent constructor? 
 just another android mystery 

 by the way, i had a glimpse of some iOs code, and must say i was startled to extent of appalled - is this C++, or some attribute based language, how do you program in this? maybe i've seen only some weird bits of code, i don't know - but i was hoping for some clean C++ code (Objective-C?) and didn't see any 

 bye..


oh yes - some helpful links, these were very helpful in grabbing some basic knowledge and sample code
- http://zaman91.wordpress.com/2010/04/22/android-how-to-start-a-service-in-application/
- http://marakana.com/forums/android/examples/60.html
- http://stackoverflow.com/questions/4480340/sample-alarmcontroller-application-service-registeration-in-androidmanifest

linux threads and forking (and zeroc ice)

so we have this nice icegrid setup with python nodes tied with sip to underlying c++ code. on new rpc call, ice creates a new thread to handle it, but as the underlying c++ code is not threadsafe we fork from this thread and continue execution in a new process.

everything works perfectly, but one day we decide to remove the python layer and go with c++ all the way

and then something weird started happening - forked processes started hanging, crashing, a total mess...after some research we found out several articles mentioning that it is a bad idea to mix linux threads and forks because of possible copied locked mutexes in the child process and this is exactly what we had observed.

so how we solve this? and why the python+cpp solution worked fine?

as a second solution we modified our code to use a thin python wrapper again over the main c++ functionality in attempt to copy the behavior from the original solution, but again the forked child processes had copied locked mutexes that caused them to hang

so, how come? in the original solution A the underlying code is pretty much the same as B and C, what appears is that some ice threads are calling localtime_r in the moment when we fork and when the forked code tries to execure localtime_r it locks.
but why does it not happen in the original python/cpp solution? why does it happen in the new python/cpp solution? are there some python flags to help avoid this? the original code would spend some time jumping from python to cpp, while the new code would only enter cpp code once and return the results.

in any case it seems a mess so we went for another completely different solution, but the headache was/is huge