terça-feira, 27 de outubro de 2009

Someone stoled my session, "And now who can defend me?"

I know that it is not nice to keep talking about Sessions, there so nice subjects out there (modularity, agile, full stack systems, etc), but they seems so far away from me that I cannot really avoid talking about Sessions.

Yesterday I recorded the problem with memory leak, which somehow is related to the HttpSessions. I believe that using a tool like a Session (which is for sure important) make us lazy.

When the system is slow, just put things on the session and everybody will be happy, but is it true? Absolutely not! Some day someone will come to your desk with a nice chart saying saying that your wonderfull application is consuming so much memory that they need to restart the server every two days.

And then what are you going to do? Once everything is binded to the session, your live will get difficult doesn't it? Well, before getting into a new project or storing your nice new object into the session take a look at subjects like REST or some frameworks like Play that avoid the use of session.
For example the framework Restlet do not supply you with any access to the session, and the Play "session" is a simple Cookie, which for sure is small enough to avoid any massive storage there.

Today I am little bit lazy, so here is a list of sites discussing it across the web (there are no state of the art, but you are all grown and can extract the best from it!):
I hope it could make we all think a little bit about it.

segunda-feira, 26 de outubro de 2009

Oh my God, I don't understand why I cannot use static maps to store user information.

Sorry folks, it was a long time since the last post, but I promisse that I am going back to stay.

Today we will take about a issue that I have heard about in the office for the whole last week: memory leak.

I believe that some memory leak is ok to happen, mainly if you store things on the HttpSession. Let's be realistics, it is a easy solution and if the data keeps on the memory for 30 minutes who cares?

But actually the memory leak that we have found is not realted to the session, it was related to the 2 different issues: thread variables and static maps.
  • Thread variables: a lot of things were being stored into the thread variable, and using as key some object. First, usually the web servers reuse the threads, so the information there was being keep for a looong time. Second object as key SHOULD-ALWAYS-NO EXCUSE TO NOT HAVE hash, otherwise baby, guess what? Every add is a new entry on the map. That's a bingo: memory leak.
  • Static maps: this is just a more obvious leak than the thread variables, use a static map to store information, where the key also do not implement a proper comparation methods. So every entry lead to a forever-and-ever information into the memory. As as Murphy says: there is always something worst, those information stored into the map where GUI objects, which was reference even to God. And the leak could lead to a OutOfMemory after 5 screen hits.

Nice ins't it? I can understand the problems, what I cannot understand is people blaming the GUI obejcts to have the necessary references. Come on, they are GUI objects that are supposed to work for a single request.
But the real problem is that people still tries to solve problems that are not present yet. The performance problems are the classical example: you never run the application, so you don't know if there is performance problems or not. Why should you address them? Why to worry about it?
Most of the problems could be solve with a proper approach to the problem and not with cache (that usually leads to a whole bunch of other problems). And if the cache is need think about what are you doing: my key if unique? is it replacing the information? what is the live time of the data? should I need another cache than the HttpSession? ...

Make like the buddhists: breath 10 times before doing something, if after that time you still want to do it, go and think about it and then do it, otherwise just go home and relax.