JMS high availability feature

The topic of this blogpost seems to be one of the most useless things in Documentum – I already mentioned that in What is wrong in Documentum. Part I, but it seems that talented team is still trying to “improve” this “feature”:

so, I think this topic deserves more thorough explanation.

Well, why do we need JMS? Frankly speaking, ten years ago I was bullshitting customers by describing JMS like: “It is an embedded application server, purposed to execute custom business logic” – means nothing, but sounds good 🙂 In real life JMS is a single point of failure which causes 80% of issues. So, if it is so unstable and affects business-users we need to stabilise it somehow – and there is a big difference between talented team and me: when I see phrase single point of failure I start thinking how to eliminate/avoid “point of failure”, when talented team see the same phrase they think about how to eliminate “single” (I have no idea why, m.b. it is just hard to read the whole phrase).

Quick question: JMS in Documentum 7.3 supports both load-balancing and failover (this was highlighted as a key enhancement) – do we really need load-balancing capabilities? How to answer to this question? Put load on Content Server and measure what resources are consumed by components, typically, I get something like:

So, Content Server consumes five times more resources than JMS, do I need to load balance JMS? Definitely not! I need to load balance Content Serves.

Now about failover capabilities. Let’s list everything which is typically executed on JMS:

  • workflow methods – I can’t understand why workflow agent is still a part of Content Server if JMS can do the same, moreover, there is no reason to failover workflow methods – slight delays in workflows, caused by JMS failures, do not affect business-users – you just need to monitor JMS health
  • job methods – the same considerations as above (dm_agent_exec is a piece of shit)
  • lifecycle methods – looks like a design gap: I can’t understand why lifecycle transitions are implemented as docbase methods: dm_bp_transition_java method just reads information about lifecycle states and executes corresponding SBOs – why do not do the same on TBO side?
  • custom docbase methods – you are a bloody idiot if custom docbase methods are a part of your application
  • mail methods – looks like a design gap too: it would be more convenient to add a special flag to dmi_queue_item objects which would indicate whether the corresponding email has been sent or not

Did I miss something? Yes, in Documentum 7.3 talented team implemented SAML authentication through JMS – taking opensource C++ implementation was too difficult.

5 thoughts on “JMS high availability feature

  1. And JMS is used by D2 to do it’s “magic” (the idiotic architecture of a client “consuming” JMS instead of CS, another possible source of problems in the chain), and I’ve seen it kill JMS due to “many” (not so many really) users simultaneously using D2 (also, before EMC decided to remove encryption for D2 communication to “reduce” stress on JMS)


  2. I believe it was covered by “custom docbase methods” item. By the way, I do think you have no idea about “idiotic architecture”, idiotic architecture is:
    * you execute docbase method to get encrypted superuser’s ticket
    * after that you take advantage of dynamic groups and become superuser to read encryption key from repository
    * having encryption key you decrypt superuser’s ticket and become superuser
    * upon save you execute SQL queries to actualise value of r_modifier attribute

    Liked by 1 person

  3. Pingback: JMS high availability feature. Part II | Documentum in a (nuts)HELL
  4. Pingback: Documentum innovations | Pro Documentum
  5. Pingback: Why exposing administrative interfaces is a bad idea | Documentum in a (nuts)HELL

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s