Name: Saju Pillai
Member since: 2006-03-20 20:07:37
Last Login: 2008-12-10 09:38:34



your friendly neighbourhood infidel

Recent blog entries by saju

6 Mar 2008 (updated 7 Mar 2008 at 02:10 UTC) »

Maybe I am not understanding this properly but java's threadlocal storage seems funky. Unlike in other non-java threading environments one cannot introspect a thread's local storage and retrieve the objects needed. To retrieve a thread local value one needs a reference to a ThreadLocal object which was used to create this TLS. This seems a bit funky; to retrieve a TLS value at a random point in that thread I need a reference to a global ThreadLocal object; so if I have to use a global object to grab TLS values I can just make my TLS values globals !

The only difference b/w globals and TLS is that the value of the TLS object can be unique per thread. This is cool but the inability to introspect a thread's TLS values without holding a global reference doesn't make sense. This stops me from using TLS where I am unable to add/modify globals for some reason (say I am writing callbacks for an established framework).

Ofcourse I probably didn't grok this right... maybe...

4 Mar 2008 (updated 4 Mar 2008 at 05:04 UTC) »

I am not a Java person and have less than a week's experience working with J2EE, maybe my brain is not wired correctly to understand Java but I have significant programming experience in multiple languages and I have never seen such a proliferation of frameworks and abuse of xml in the name of declarative programming. Most of the latest Java based frameworks have a large amount of documentation explaining how they are different from the other frameworks and how using their framework apparently makes it easier for the programmer to concentrate on business logic and forget about the "grunt" work and loose ends. This clearly seems like a bunch of authors writing a lot of code to create a fwmk/api based on an idea which was simply not significantly different from the previous fmwk to stand on it's own merit.

Also why do most new java fmwks/api's state one of their goals as "making programming easier" ? Surely the J2EE programmer is smart enough to know that he should close files he has opened in his program ? Surely the answer to a bad programmer is not to create a brand new framework that closes opened files via code injection and declarative xml programming. If there is a problem with a existing framework or an api - maybe everyone should just try fixing it ?

I definitely don't have enough exposure to understand all the problems of Java or J2EE and the need for so many frameworks so you could definitely say I not qualified to comment on something that I obviously don't understand well enough. In my defense; neither do I have any significant experience in say Python, Lisp or Perl but I can already see that they have got their story right. Maybe after you have spent enough hours hacking stuff at ungodly hours, you just develop a sense of what is right and what is not, and Java and it's framework hell just does not seem right

I saw Spiderman-3 yesterday. It should have been named Mary Jane - 1. I was still recovering from the shock of watching Transformers, when I had to endure all that crappy teenage angst of spidey3.

Current mood - Disturbed

16 Feb 2008 (updated 16 Feb 2008 at 15:58 UTC) »

Just got a shiny new Dell E248WFP monitor. Awesome good. Hooked up my Macbook Pro to the monitor and everything works great. Well almost everything. "Mirror mode" forces the monitor resolution to drop to the macbook's resolution.

I will get myself a nice USB mouse and keyboard tommw and run my macbookpro in "clampdown mode". That should make me happy mmmm..

15 Feb 2008 (updated 15 Feb 2008 at 15:41 UTC) » adventures

I recently had to write a server in java that can speak SSL/TLS. The actual application protocol is handled by classes upstream to the SSL/TL layer. For scalability I decided to use Java NIO - which implied using the

The SSLEngine api is pretty cool though could possibly be a bit better designed. Essentially the application needs to manage 4 buffers of data, 2 of which are read by and 2 of which are written to by the SSLEngine. Sounds easy, infact it is, if it were not for the Handshake and renegotiation. Calling an api on the SSLEngine can cause it to ask you to call another api which may in turn ask you to call the original ... and so on.

I first wrote the SSL layer using recursion but with upto 5 exit points and special code to take care of stack unwinding and having to manipulate global buffers this was deemed too risky. So I re implemented the SSL engine via state transition. Since I was already playing with NIO and had to use a thread pool to handle concurrent clients, I decided to make the SSL processing asynchronous. Essentially I broke down the SSL processing (including breaking down the handshake and app layer protocol parsing) into various states, the currently executing thread would finish executing 1 state and hand over the "session" to the thread pool where another free thread will finish the next state. Ofcourse I have coded in optimization where an implementation of a state can decide whether to transition over a thread boundary or force the current thread to execute the next state.

Long story short. It works andit fits very nicely into the server's threading model.

11 older entries...


Others have certified saju as follows:

  • rmathew certified saju as Apprentice
  • ncm certified saju as Apprentice
  • fzort certified saju as Apprentice

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page