– Tony, there is a man I’d like you to find.
– Well, that depends on all the elements in the equation. How many are there?
– Forty thousand.
Yeah, in case of Documentum there are too many elements it the equation, and all customer teams I have seen before fails to troubleshoot performance issues – in most cases they try to ask somebody else for help, and the most stupid idea here is to ask the vendor.
Well, imagine you have identified that some Documentum activities got stuck due to a lock in database, i.e. from database perspective you are observing something like this:
what will be the next step in your troubleshooting investigation? Some guys think that it is a good idea to kill blocking session or bounce everything 🙂 This is wrong! At first we need to understand where has the blocking session came from and what is it currently doing. In order to do so I have written a simple SQL query which may give some clues for the problem:
Now we know outgoing TCP port for Documentum process and can identify documentum session and corresponding java application:
Now we know where blocking session has came from, how to identify corresponding execution stack? The simplest way is to make a dump of heap, find there com.documentum.fc.client.impl.session.Session objects and compare their m_connectionId with documentum session identifier found previosely, m_transationThread is what we are looking for:
but for web applications I have written a simple jsp which do the same in a more simple manner: