Friday, September 27, 2013

Last minute fixes

I hate last minute fixes and especially on things that I dont understand much.

Today is release day and I was called by my product manager friend about some bug that I had no clue what that feature was.

With some help from product manager I was able to reproduce the issue locally and 90% of the problem is solved when you can reproduce the issue. So it took 30 min to fix it as it was an easy fix.  It took more time to merge the damn fix. The reason was that developer had totally different packages in release and trunk and also in trunk there were many private interface changes.

The bug has been there for 2 weeks in production so why was it detected after 2 weeks. Two reasons:
1) This was some custom feature developed for only this customer. I hate these WTF custom feature.
2) Well it seems the customer already knew about the bug and Professional services schedules calls on Friday and Friday night is our release so customer waited a week to tell us.

Nothing can be done about custom features as its enterprise world and you have to bow to customers requirement most of the times but the professional services can reschedule the meeting to Wednesday or something to give us more breathing  room.

Friday, September 13, 2013

Applet and httpOnly session cookies

We use jfileupload applet in our cloud server to allow users to upload folder hierarchy from browser.

Recently our security team found an issue that if our site was vulnerable to XSS then anyone can read the jsessionid cookie.  To fix this I changed the tomcat server.xml context attribute useHttpOnly="true" and most of the things were fine but the applet broke.

now it was giving me nothing except "unable to load" and NullPointerException string (no stacktrace) in applet console.  I first thought its some local issue but then  I tried from multiple machines and same issue. Googling didnt helped.

Finally after spending 3-4 hours I found that when applet tries to download the jar files the request were coming to tomcat and we were applying a WebSessionFilter that would redirect requests with no sessions to login page.

Skipping .jar files download from session filter  check solved the issue.  (I know, I know we should have used apache to serve the jar files and thats what we use in production but local developers usually dont run the entire stack and I had shut down apache locally).

Tuesday, September 10, 2013

weird memcached behavior

I need to chase this but when I ran memcached-top command on our prod boxes I saw we had 1:20 read vs write ratio.


INSTANCE USAGE HIT % CONN TIME EVICT READ WRITE
memcache01:12345 85.8% 94.7% 4039 1.1ms 1.5M 4.3T 80.9T
memcache02:12345 85.8% 93.4% 4022 1.2ms 1.6M 4.7T 80.5T

This is throwing me off. I will analyze to see what i causing it because we should technically see more reads and less writes.

Monday, September 2, 2013

injecting a request attribute into a jersey rest api

My colleague made an interesting command that AOP is like a drug and once you have tasted it you can spot cross cutting concerns and the mere presence of duplicate code tells you the signs of martin's fowler's bad smell in code.  

We use jersey to implement rest apis and our rest apis can be called from Session or BasicAuth or Oauth, after a user is successfully authenticated we inject the caller user object in request as an attribute so the rest api can derive it to further make api level business validation.  But that means every api method has to write this ugly piece of code where we inject request into the signature and then add this one line of code to get the user object.
 
    public Response getDevicesForCustomer(@Context HttpServletRequest request, ....) {
        User user = (User) request.getAttribute("user");
...
}


This sounds like a perfect cross cutting concern to be baked into AOP layer. What would be nice if we could do it like this

    public Response getDevicesForCustomer(@Context User  user ....) {
...
}


so it seems its pretty easy to do this in jersey, all you need is to implement a provider and one fellow programmer's blog gave me the ideas that we can even make it with generic templates so I broke the class into two.
public abstract class AbstractRequestAttributeInjectableProvider<E> implements
        InjectableProvider<Context, Type>, Injectable<E> {

    private final Type t;
 
    protected @Context HttpServletRequest request;
 
    public AbstractRequestAttributeInjectableProvider(Type t) {
        this.t = t;
    }

    @Override
    public Injectable<E> getInjectable(ComponentContext ic, Context a, Type c) {
        if (c.equals(t)) {
            return this;
        }

        return null;
    }

    @Override
    public ComponentScope getScope() {
        return ComponentScope.PerRequest;
    }
}

and then our final User injector

@Provider
public class UserProvider extends AbstractRequestAttributeInjectableProvider<User> {
    public UserProvider() {
        super(User.class);
    }

    @Override
    public User getValue() {
        return (User) request.getAttribute("user");
    }
}


Tada  lots of boilerplate code is gone.