Saturday, June 13, 2009

Blog reading saturday, and what's up in Eclipse Support

Rainy morning here. Thru Ian blog I just came accross his University Lab blog and found myself thinking how simple ideas are still so fresh in different contexts. Think corporate blogs - exist, companies blogs - exist, communities blogs - exist, political parties - some do. But University having a blog? Last week, partying with my team, we've thrown the same idea worthless. Universities, at least where I live, are fed by publications and citations counts - so why should they bother about blogs?

Kuba, from my team, wasn't there last time, but he actually works on PhD, so I just asked him why don't our Univ still have blog? Actually it turns out, things are in progress(!). So some day I might be able to learn what's on my friendly Software Engineering experts minds :-) Well having a blog might actually be helpful, because researchers are always struggling to get their way to companies, to work on real cases. However they might not see that from business people perspective, they're no easier to find too. Single blog is not a cure for all the communication problems, but looking at yourself when you don't understand how to reach others might be helpful.

Ok, so now I see my blog. How dusty here. So what cool actually happend in IBM Eclipse Support center recently?? I'll write about two things.

I'm co-mentoring one of Google Summer of Code projects, namely OSGi Monitoring. Our student Wojtek is working on getting PDE Plug-in registry view able to get some insight of self-hosted Eclipse instance, remote Eclipse instance or maybe even non-Equinox one. It's a UI version of -console. So far he went over various communication layer implementations - socket connection, ECF, R-OSGI (thanks Scott!), JMX. After he passes his exams, I hope to finally see we start, stop, install and inspect all my Eclipse instances from the machine next to me!

The other thing I wanted to write about is not that promising. Since January or Feb, we were having a customer with really bad issue. He works with several Eclipse-based IBM products but for some reason his editors are slow as hell. But what's the problem we asked; what's slow, how do you see it? He uses Eclipse text editor, JDT Java editor, and various other editors to write his scripts in a multiuser environment based on Windows network shared drives. Shared drive and text editor? You sense the catch. He must be hitting some network delays! To spice things up, issue happens only in very specific setup, different product teams suspect that the other product is failing and any kind of remote assistance is hardly possible due to security and network reasons. And finally, how to find the reason for 1-2 sec. freezes that happen only when making mouse clicks? Here Eclipse support team kicked in! The Java coredumps would help - they cleanly show what's going on in the threads. Going that path we wrote a small plug-in that drops core dumps on any hangs in Display thread. And that was the hit. It turned out a couple of plug-ins had poor selection change listeners implementations. They were making calls like java.io.File.exists() - you woudn't normally see anything wrong with that. But if the file is on shared drive a couple of calls like that easily take 1sec. - just enough to turn any excellent editor to crap! And that was it - few different components did the same fault with calling java.io APIs on selection change. Now they're working on fixing that. I hope your selection listeners don't have that bug :-)

3 comments:

Ankur Sharma said...

Interesting! Never occurred to me that File.exists() can be such a trap. But then what is the way out? Does EFS provides a better way of finding if a file exists or not?

Jacek Pospychala said...

One way is to cache that information. If I remember correctly, some text editor facilities (document provider?) used FileInfo from o.e.core.filesystem API and kept object for future.

Tomasz Zarna said...

Good job guys! Two thumbs up :)