“Talented” – what does it mean?

Have noticed an odd tendency to use “talented” epithet when OpenText reps talk about former EMC/IIG/ECD employees, some examples:

OpenText Strengthens EIM Portfolio with Completion of ECD Acquisition, by Mark Barrenechea:

Along with product enhancements and a worldwide customer base of more than 5,600, the acquisition brings 2,000 talented ECD employees to the OpenText family. Together, we will be over 10,000 professionals strong, focused on customer success in EIM and enabling the digital world.

Documentum and OpenText for Life Sciences – Moving Beyond FUD, by Jaleel Shujath:

To summarize, the OpenText Documentum for Life Science Solution Suite has the investment it needs and a talented team to drive its functionality forward. Additionally, we’ll continue to help Life Sciences organizations realize the potential of EIM to deliver the real benefits of Digital Transformation.

Why does this epithet confuse me? I’m not sure about other countries (or nationalities), but for Russians, when we are talking about “talent”, we mean some perspectives rather than professionalism or achievements, for example the phrase “talented scientist” causes our imagination to draw a character of a student or postgraduate, who has some perspectives, but we definitely do not imagine a honoured elder. So, I decided to investigate what does the “talented” epithet mean in different languagescountries and have found a totally weird interpretation:

British informal People regarded as sexually attractive or as prospective sexual partners.
‘most Saturday nights I have this urge to go on the hunt for new talent’

LOL 🙂

Side effects of dfc.diagnostics.resources.enable

Assuming that I set correct credentials and we do know how to set dfc preferences in runtime, what does code below print?

@Test
public void test() throws Exception {
    int count = 0;
    try {
        DfPreferences preferences = DfPreferences.getInstance();
        preferences.loadProperty(DfPreferences.DFC_SESSION_MAX_COUNT, 50);
        while (++count > 0) {
            IDfClientX clientX = new DfClientX();
            IDfClient client = clientX.getLocalClient();
            IDfSessionManager sessionManager = client.newSessionManager();
            IDfLoginInfo loginInfo = clientX.getLoginInfo();
            loginInfo.setUser("dmadmin");
            loginInfo.setPassword("dmadmin");
            sessionManager.setIdentity("DCTM_DEV", loginInfo);
            IDfSession session = sessionManager.getSession("DCTM_DEV");
        }
    } finally {
        System.out.println("Session count: " + count);
    }
}

Actually, the answer is obvious – that buggy code creates 50 sessions and fails:

Session count: 50

DfServiceException:: THREAD: main; MSG: [DM_API_E_NO_SESSION]error:  "There are no more available sessions."
; ERRORCODE: 100; NEXT: null
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.getConnectionFromPool(DocbaseConnectionManager.java:168)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.getDocbaseConnection(DocbaseConnectionManager.java:94)
	at com.documentum.fc.client.impl.session.SessionFactory.newSession(SessionFactory.java:23)
	at com.documentum.fc.client.impl.session.PrincipalAwareSessionFactory.newSession(PrincipalAwareSessionFactory.java:44)
	at com.documentum.fc.client.impl.session.PooledSessionFactory.newSession(PooledSessionFactory.java:49)
	at com.documentum.fc.client.impl.session.SessionManager.getSessionFromFactory(SessionManager.java:134)
	at com.documentum.fc.client.impl.session.SessionManager.newSession(SessionManager.java:72)
	at com.documentum.fc.client.impl.session.SessionManager.getSession(SessionManager.java:191)
	at SessionDemo.test(SessionDemo.java:30)

Now, less obvious code:

@Test
public void test() throws Exception {
    int count = 0;
    try {
        DfPreferences preferences = DfPreferences.getInstance();
        preferences.loadProperty(DfPreferences.DFC_SESSION_MAX_COUNT, 50);
        preferences.loadProperty(DfPreferences.DFC_DIAGNOSTICS_RESOURCES_ENABLE, true);
        while (++count > 0) {
            IDfClientX clientX = new DfClientX();
            IDfClient client = clientX.getLocalClient();
            IDfSessionManager sessionManager = client.newSessionManager();
            IDfLoginInfo loginInfo = clientX.getLoginInfo();
            loginInfo.setUser("dmadmin");
            loginInfo.setPassword("dmadmin");
            sessionManager.setIdentity("DCTM_DEV", loginInfo);
            IDfSession session = sessionManager.getSession("DCTM_DEV");
        }
    } finally {
        System.out.println("Session count: " + count);
    }
}

the result is bit confusing – code creates more than 50 sessions and fails:

...
25586 [Resource Housekeeper] ERROR com.documentum.fc.client.impl.session.StrongSessionHandle$DisposableData  - [DFC_SESSION_NOT_RELEASED] Unreleased session found during garbage collection, Session{id=29, iid=29, serial=1, docbase=DCTM_DEV, user=dmadmin, serversession=none}
com.documentum.fc.impl.util.ThrowableStack: Stack when session was obtained
	at SessionDemo.test(SessionDemo.java:31)
...

Session count: 94

DfServiceException:: THREAD: main; MSG: [DM_API_E_NO_SESSION]error:  "There are no more available sessions."
; ERRORCODE: 100; NEXT: null
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.getConnectionFromPool(DocbaseConnectionManager.java:168)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.getDocbaseConnection(DocbaseConnectionManager.java:94)
	at com.documentum.fc.client.impl.session.SessionFactory.newSession(SessionFactory.java:23)
	at com.documentum.fc.client.impl.session.PrincipalAwareSessionFactory.newSession(PrincipalAwareSessionFactory.java:44)
	at com.documentum.fc.client.impl.session.PooledSessionFactory.newSession(PooledSessionFactory.java:49)
	at com.documentum.fc.client.impl.session.SessionManager.getSessionFromFactory(SessionManager.java:134)
	at com.documentum.fc.client.impl.session.SessionManager.newSession(SessionManager.java:72)
	at com.documentum.fc.client.impl.session.SessionManager.getSession(SessionManager.java:191)
	at SessionDemo.test(SessionDemo.java:31)

another code:

@Test
public void test() throws Exception {
    int count = 0;
    try {
        DfPreferences preferences = DfPreferences.getInstance();
        preferences.loadProperty(DfPreferences.DFC_SESSION_MAX_COUNT, 50);
        preferences.loadProperty(DfPreferences.DFC_DIAGNOSTICS_RESOURCES_ENABLE, true);
        while (++count > 0) {
            IDfClientX clientX = new DfClientX();
            IDfClient client = clientX.getLocalClient();
            IDfSessionManager sessionManager = client.newSessionManager();
            IDfLoginInfo loginInfo = clientX.getLoginInfo();
            loginInfo.setUser("dmadmin");
            loginInfo.setPassword("dmadmin");
            sessionManager.setIdentity("DCTM_DEV", loginInfo);
            IDfSession session = sessionManager.getSession("DCTM_DEV");
            System.gc();
        }
    } finally {
        System.out.println("Session count: " + count);
    }
}

the result is weird – code prints a lot of diagnostics messages but does not fail:

...
115902 [Resource Housekeeper] ERROR com.documentum.fc.client.impl.session.StrongSessionHandle$DisposableData  - [DFC_SESSION_NOT_RELEASED] Unreleased session found during garbage collection, Session{id=1, iid=1207, serial=1, docbase=DCTM_DEV, user=dmadmin, serversession=none}
com.documentum.fc.impl.util.ThrowableStack: Stack when session was obtained
	at SessionDemo.test(SessionDemo.java:31)
...

and the last example:

@Test
public void test() throws Exception {
    int count = 0;
    try {
        DfPreferences preferences = DfPreferences.getInstance();
        preferences.loadProperty(DfPreferences.DFC_SESSION_MAX_COUNT, 50);
        preferences.loadProperty(DfPreferences.DFC_DIAGNOSTICS_RESOURCES_ENABLE, true);
        while (++count > 0) {
            IDfClientX clientX = new DfClientX();
            IDfClient client = clientX.getLocalClient();
            IDfSessionManager sessionManager = client.newSessionManager();
            IDfLoginInfo loginInfo = clientX.getLoginInfo();
            loginInfo.setUser("dmadmin");
            loginInfo.setPassword("dmadmin");
            sessionManager.setIdentity("DCTM_DEV", loginInfo);
            IDfSession session = sessionManager.getSession("DCTM_DEV");
            session.beginTrans();
            System.gc();
        }
    } finally {
        System.out.println("Session count: " + count);
    }
}

result is even more weird – code does not print diagnostic messages and fails:

4964 [Resource Housekeeper] ERROR com.documentum.fc.client.impl.connection.docbase.DocbaseConnection  - Connection put back in pool with transaction active, Connection{id=1, docbase=DCTM_DEV, user=dmadmin, state=FREE}

Session count: 50

DfServiceException:: THREAD: main; MSG: [DM_API_E_NO_SESSION]error:  "There are no more available sessions."
; ERRORCODE: 100; NEXT: null
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.getConnectionFromPool(DocbaseConnectionManager.java:168)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.getDocbaseConnection(DocbaseConnectionManager.java:94)
	at com.documentum.fc.client.impl.session.SessionFactory.newSession(SessionFactory.java:23)
	at com.documentum.fc.client.impl.session.PrincipalAwareSessionFactory.newSession(PrincipalAwareSessionFactory.java:44)
	at com.documentum.fc.client.impl.session.PooledSessionFactory.newSession(PooledSessionFactory.java:49)
	at com.documentum.fc.client.impl.session.SessionManager.getSessionFromFactory(SessionManager.java:134)
	at com.documentum.fc.client.impl.session.SessionManager.newSession(SessionManager.java:72)
	at com.documentum.fc.client.impl.session.SessionManager.getSession(SessionManager.java:191)
	at SessionDemo.test(SessionDemo.java:31)

Corresponding thread dump:

"Resource Housekeeper" #13 daemon prio=10 os_prio=31 tid=0x00007fb78c1bd800 nid=0x5703 in Object.wait() [0x0000700001452000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000006c0dc9828> (a com.documentum.fc.client.impl.connection.docbase.DocbaseConnection)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.waitForCorrectSharingContext(DocbaseConnection.java:820)
	- locked <0x00000006c0dc9828> (a com.documentum.fc.client.impl.connection.docbase.DocbaseConnection)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.evaluateRpc(DocbaseConnection.java:1108)
	- locked <0x00000006c0dc9828> (a com.documentum.fc.client.impl.connection.docbase.DocbaseConnection)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.applyForBool(DocbaseConnection.java:1198)
	- locked <0x00000006c0dc9828> (a com.documentum.fc.client.impl.connection.docbase.DocbaseConnection)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.apply(DocbaseConnection.java:1183)
	at com.documentum.fc.client.impl.docbase.DocbaseApi.endTrans(DocbaseApi.java:1757)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.cleanupFromUnexpectedTransactionState(DocbaseConnection.java:729)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.quiesce(DocbaseConnection.java:663)
	- locked <0x00000006c0dc9828> (a com.documentum.fc.client.impl.connection.docbase.DocbaseConnection)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.returnConnectionToPool(DocbaseConnectionManager.java:663)
	at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.release(DocbaseConnectionManager.java:270)
	at com.documentum.fc.client.impl.session.Session.releaseConnection(Session.java:248)
	at com.documentum.fc.client.impl.session.PooledSessionFactory$SessionListener.onDisconnect(PooledSessionFactory.java:114)
	at com.documentum.fc.client.impl.session.Session.notifyListenersOfDisconnect(Session.java:395)
	at com.documentum.fc.client.impl.session.Session.disconnect(Session.java:312)
	at com.documentum.fc.client.impl.session.Session.decrementReferenceCount(Session.java:3687)
	at com.documentum.fc.client.impl.session.StrongSessionHandle$DisposableData.dispose(StrongSessionHandle.java:127)
	at com.documentum.fc.internal.reshousekeeper.ResourceHousekeeper$1$1.run(ResourceHousekeeper.java:52)

Try to explain results 🙂

Another PostgreSQL challenge

Tried to install Documentum/PostgreSQL and got following error:

[SQL]   1006     CREATE  VIEW dm_acl_rp(r_object_id,i_position,i_partition,r_accessor_name,r_accessor_permit,r_accessor_xpermit,r_is_group,r_permit_type,r_applicati
on_permit)  AS  SELECT VE_.r_object_id,VE_.i_position,VE_.i_partition,VE_.r_accessor_name,VE_.r_accessor_permit,VE_.r_accessor_xpermit,VE_.r_is_group,VE_.r_permit_type,VE_.r_application_permit FROM dm_acl_r VE_  0.0008960000
[SQL]   1006    EXEC    0.0009740000
[SQL]   1006    Commit
[SQL]   1006    Commit
[SQL]   1006     INSERT  INTO dm_type_s VALUES('0302994880000100','dm_acl',' ',        21,         0,'dctm','1f02994880000101','1f02994880000102','2e02994880000101'
,1,         0,         0,        22,' ',-2147483392, timestamp '2017-03-11 12:46:45.000' , timestamp '2017-03-11 12:46:45.000' ,         0) 0.0010860000
[SQL]   1006     -- Object already exists --  STATE=23505, CODE=1, MSG=ERROR: duplicate key value violates unique constraint "d_1f02994880000008";
Error while executing the query

[DM_TYPE_MGR_E_CANT_SAVE_TYPE]error:  "Failure to insert row for type dm_acl in table dm_type_s: error from database system is  -- Object already exists --  STATE=23505, CODE=1, MSG=ERROR: duplicate key value violates unique constraint "d_1f02994880000008";

The root cause was that new ODBC driver (psqlODBC 09.06.0100) seems to be incompatible with Documentum, switching to previous version (psqlODBC 09.05.0400) resolves the problem.

Mature product :)

First time when I had faced with REFRESH_JMS_CONFIG_LIST RPC-command my thoughts were: what an idiot implemented this? What was the point to increase refresh interval upon failure? Why do not take advantage of application listeners and to not perform REFRESH_JMS_CONFIG_LIST call automatically upon JMS startup? But it seems that in 7.3 EMC has gone even further: