Thanks for reply. It does not happen all the time. I saw this twice and could not easily reproduce it. Next time I will try testing it with jpda enabled.
I am not sure if I am doing something wrong in the data model. First I fill the FastMap with data read from external data source. Then I iterate all entries in FastMap and find a set of items that I don't need. Finally I iterate the entries again to remove those items from FastMap. If the item set of any userID becomes empty, the userID will be removed from FastMap too. Maybe I should do these outside mahout using ordinary Map? Thanks, Weiwei 2009/12/4 Sean Owen <[email protected]> > It is not deadlock, since that would result in the app doing nothing, > not consuming CPU. From the threads you dumped, I only see one waiting > on a lock; deadlock would involve two threads waiting on locks. > > The "infinite loop" sounds more likely, as it would explain what you > see. It would have to be the while loop. I am having trouble seeing > how it could fill up with all non-null entries, since it grows when it > gets pretty full. The "jump" should also touch all entries since the > size of the hashtable is prime, no matter what the jump is. > > Any chance you can debug and look at the contents of the FastMap at > that point? that would be a clue about the nature of the problem. > > On Fri, Dec 4, 2009 at 10:14 AM, 施伟伟 <[email protected]> wrote: > > Hi, > > > > I found my application based on mahout using 99% CPU after load testing. > > There is no actual requests at the moment but the CPU usage kept high. > > I generated several thread dump and found one thread may be get stuck an > > endless loop in FastByIDMap.find(). > > I am not sure what is the problem is. I am using customized data model > > implemented by myself. It is more or less the same as FileDataModel but > > reading data from a different data source. > > Please find the detailed info below. > > > > Thanks, > > Weiwei > > > > private int find(long key) { > > int theHashCode = (int) key & 0x7FFFFFFF; // make sure it's positive > > long[] keys = this.keys; > > int hashSize = keys.length; > > int jump = 1 + theHashCode % (hashSize - 2); > > int index = theHashCode % hashSize; > > long currentKey = keys[index]; > > while (currentKey != NULL && (currentKey == REMOVED || key != > > currentKey)) { > > if (index < jump) { > > index += hashSize - jump; > > } else { > > index -= jump; > > } > > currentKey = keys[index]; > > } > > return index; > > } > > > > Below is the thread dump. > > > > This is the thread that got the lock in > > org.apache.mahout.cf.taste.impl.common.Cache.get > > "http-10.90.39.156-23869-Processor24" daemon prio=1 tid=0x085bb618 > > nid=0x4f5f runnable [0x825a8000..0x825a8f30] > > at > org.apache.mahout.cf.taste.impl.common.FastMap.find(FastMap.java:113) > > at > org.apache.mahout.cf.taste.impl.common.FastMap.get(FastMap.java:123) > > at org.apache.mahout.cf.taste.impl.common.Cache.get(Cache.java:74) > > - locked <0x96eadf98> (a > org.apache.mahout.cf.taste.impl.common.FastMap) > > at > > > org.apache.mahout.cf.taste.impl.recommender.CachingRecommender.recommend(CachingRecommender.java:118) > > > > > > This is the thread that is blocked in > > org.apache.mahout.cf.taste.impl.common.Cache.get. There are hundreds of > such > > threads in my thread dump file. > > "http-10.90.39.156-23869-Processor272" daemon prio=1 tid=0x08405d78 > > nid=0x5479 waiting for monitor entry [0x731ef000..0x731f0130] > > at org.apache.mahout.cf.taste.impl.common.Cache.get(Cache.java:73) > > - waiting to lock <0x96eadf98> (a > > org.apache.mahout.cf.taste.impl.common.FastMap) > > at > > > org.apache.mahout.cf.taste.impl.recommender.CachingRecommender.recommend(CachingRecommender.java:115) > > >
