Friday, August 27, 2004
After 94, I've met lots of smart ppl at work. However they are not hackers, they are more into how to design things right and efficiently, instead of curuosity driven playing with toys. Since I got paid for working for big bank, big names, it is the career path I took. Bascially working among most of company drones with accasionaly bumped into some smart ppl but no hackers any more. However I am still curiosity driven, such as learned Python, Jython and loz of other things along the road. It is painful sometimes you work with drones since you need to talk in the language they can understand. Surprisly, I am a very good teammate and get along with everyone. I think it is because I know they want me as a helper, touble shooter, a developer. But I know deep inside me I like to be a great hacker, who is always curious and learning about things that I dunno about.
This year (2004) has been quite an interesting year for me in terms of updating loz of IBM product experience such as DB2, WAS 5, WSAD 5, MQ 5.3. It is like hacking sometimes, you need to read loz of docs, play with loz of toys, then suddendly had an idea or two on how to do things better. That drove me to wrote a tool for WAS, an article for DB2.
The years at GIT really helped me to develop a long term attitute towards my career. And those guys really inspired me to create more fun at work.
Wednesday, August 25, 2004
This tool comes from the real experience of WAS 5 class loader trouble shooting I've been thru. I've been doing some support for the tool CFT at Alphaworks. Its feedback is pretty positive. The tool itself is written in Jython and Java on top of Mbean API. It took me a while to coin up the whole idea.
I am glad this tool makes some people 's life easier. It is fun to have an idea, make it work and support it.
I added some functions customers wanted and send out the update to IBM.
It is useful for troubleshooting (with turning JSSE tracing on) and helped one of my coworker to slove his AD problem which turns out to be a SSL cert problem.
Things that are interesting:
1. I used a local trust store instead of messing up the JRE's cacerts.
2. LDAPS uses 636 as default port.
3. I use Jython for gluing java code (JNDI/LDAP bind, search). My view of using jython is use as much Java library (JNDI provider in this case) as possible. The reason is simple, our applications are written in Java and I want to mimic the behavior of the applications as a LDAP client. Then Why use Jython? it is darn fast for me to change the code hence timer saver. So I can enjoy more life besides coding:-).
Monday, August 23, 2004
Someone added an interface (with only 1 method) to the bean's remote but forgot to mark the method as "READ".
According to someone familiar with EJB container in WAS, the container will issue an "UPDATE" to DB2. This is the root cause of our extra UPDATE and actually caused deadlocks for us. It 's good to know and make me more frustrated and wonder why it has been designed this way. It doesn't seem be coming from EJB spec. sigh.. i guess welcome to the real and dark side of EJB which doesn't seem to be cool at all.
The complexity of EJB esp. CMP implementation can easily go beyond what average developer's brain can handle. I don't feel I'd love to program this way but being forced to.
The bad thing about the the park and beach is too packed and there is a tournament every other week and made it even worse. sigh.. toronto has too many ppl living now.. it is funny to see those towtrucker are making quick cashes by putting cars on their trailer and a cop writing a ticket at the same time. They do work like buddies:-).
Monday, August 16, 2004
#2 - The second rule of Fight Club is, you DO NOT talk about Fight Club.
#3 - If someone says stop, goes limp, taps out, the fight is over.
#4 - Two guys to a fight.
#5 - One fight at a time.
#6 - No shirts, no shoes.
#7 - Fights will go on as long as they have to.
#8 - If this is your first night at Fight Club, you have to fight.
At first, it is hard to reproduce. So I used a tool called Silk Peformer to make it reproducable by stressing the application gradually. Then take a DB2 event monitor during running the script. The hardest part is to match WAS trace.log (by Java thread id) and the huge DB2 event monitor log (by DB2 application handle). Moreover, I got to talk to some developers who are familar with the business logic involved here to understand why it does that etc.
It is hard but rewarding to see why deadlocks happened. It will be nicer to have a tool for DB2 event monitor log. I want to see sorting by application handle and search by SQL statement too.
Steps for deadlock solving.
Take a closer look at DB2 event monitor log, esp. how many applications has been involved. Draw a diagram whenever possible.
Search the java/jsp code with deadlocked SQL and get a list of possible class and method involved.
3. we have been doing it bottom up, now go read Java code that involved in different threads. see if any Java/JSP that found in 2. are involved here.
Read WAS trace log to verfiy that.
4. There are two possibilities source of deadlock,
a. coming from application code. It can be verfied thru inserting a java
stack trace at the method level.
b .coming from EJB container.
It can come from unmarked "READ" (access intent) remote method.