nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

LAPI Duplicate Documents

Pfizer_Developers

Hi All,

We're using LAPI in a Java application (LL 9.1) to create new documents in Livelink using CreateObjectEx and CreateVersion. What we're finding is that if there are multiple users using this functionality (we notice this with 4+ users), some documents are randomly loaded twice.

Logging in the Java code shows that the CreateObjectEx and CreateVersion calls are only happening once, not twice, for the documents in question. So the issue does not appear to be with the Java code itself, but the issue is happening sometime after the methods are executed.

We have noticed occasional LLIllegalOperationExceptions at times of high load, but the exception handling code works and the documents are typically loaded normally. In fact, most of the time, the documents that are doubled were not ones that were associated with an exception.

Appreciate any input here - we're nearly at a loss for what could be wrong.

Thanks for your time.

Rick

Find more posts tagged with

Comments

Carsten_Kulms

Do you use a single LLSession instance in your application? If so this could explain the observed issues since LLSession is _not_threadsafe.Each of your application's threads should work with an own instance.

Pfizer_Developers

OK, this is very useful. So each user should instantiate their own LLSession, create their own LAPI_DOCUMENTS, etc... Is there a particular way to kill the session object after the user's request is done, or just set it to null? Also, would you suggest creating a new session for each CreateObjectEx call, or just associating one session with all the calls the user will make?

Thanks for your help,

Rick

Carsten_Kulms

There is no need to 'kill' a LLSession object, just let the GC clean itaway.It is OK to use a single LLSession instance for all calls of a singleuser. Actually you can reuse a LLSession instance in an e.g. "worker thread"processing request of different users -- if the same account is used forall users or performing impersonation -- _but_ you need one LLSessionper such thread.

Pfizer_Developers

Thank you for the advice. We'll give this a try and see how it goes.

Pfizer_Developers

So we're implemented the code as you've suggested, and we're seeing the same behavior, albeit not as often as previously.

What we're seeing in the logs appears to be that if there is a lot of latency between the time one of the calls starts, and when it finishes, we'll sometimes get two records created.

For example, in one instance the CreateObjectEx call started, then completed a few seconds later. Then the CreateVersion call started, but didn't complete until two minutes later. In those two minutes, we ended up with two identical objects. In the log, the code reported that the document loaded successfully and gave the dataid of the NEWER document.

Could this latency be causing the issue, and if so, how can we deal with that?

Thanks again,

Rick

Appu_Nair

I would like to echo what Carsten said ,every instance of the program should use the session

It creates

What I think you could probably be running into is thread saturation .A Livelink server

Instance has only 5 threads so you should try to see if you are running into thread contention.

If you can create some more instances of Livelink server a 4 Gb FE can easily handle another instance on a different port that is.

A good step will be to put wantSummaryTimings=true and see if the lapi requests are captured and analyze it using a tool

Like perfAnalyzer

From: eLink Entry: LAPI Forum [mailto:lapi@elinkkc.opentext.com]
Sent: Tuesday, December 14, 2010 1:13 PM
To: eLink Recipient
Subject: RE RE LAPI Duplicate Documents 2

RE RE LAPI Duplicate Documents 2

Posted by pfizerdevteam (Developers, Pfizer) On 2010/12/14 14:12

So we're implemented the code as you've suggested, and we're seeing the same behavior, albeit not as often as previously.

What we're seeing in the logs appears to be that if there is a lot of latency between the time one of the calls starts, and when it finishes, we'll sometimes get two records created.

Could this latency be causing the issue, and if so, how can we deal with that?

Thanks again,

Rick

[To post a comment, use the normal reply function]
Topic:	LAPI Duplicate Documents
Forum:	LAPI Forum
Livelink Server:	knowledge-wlweb01

Pfizer_Developers

In this case we're trying to implement a "while you wait" type of a loader. At first, I thought the number of threads might be an issue, so we tried to write a class that would keep one static LLSession synchronized, so it would only be accessed by one user at a time. This design still exhibits the same behavior.

Installing another instance of Livelink would really complicate the design of the solution. Is there any way to programmatically ensure that there are enough Threads available before a session is created, and if there are not, wait until a thread opens up?

Thanks for everyone's input!

Carsten_Kulms

Hmm, that sounds strange.What exactly do you mean with " two identical objects" -- afaik it isimpossible to create two objects with same name at the same location(folder).Of course you can create two versions of a document with the same name-- is that what you observe?Currently I have no solutions, only a few hints where/how to look forfurther evaluation:- on the LES server turn on "Detailed Thread Logging" (in opentext.inifile this is Debug=2), this gives you thread...log files- there is also a setting "wantLAPILogs" in the opentext.int, set it totrue; this gives you details about the LAPI calls in the thread..logs- maybe to much but it may prove helpful possibly: also trun on"database logging" (this gives you deep details in connect...log files)- you may (if possible in your setup) route the LAPI requests throughsome 'proxy' which can log the raw TCP/IP communication or capture itwith a tool like WireShark, or Ethereal- use different user accounts at LAPI level for each thread / LLSession(if not already the case); this may ease the analysis of the log files- inspect the Audit log of the created documents/versions to figure outwhat was going on (see also the previous point)

Carsten_Kulms

Creating a LLSession object in your application (the LAPI client) doesnot consume any resources on the LES server.Once you issue a LAPI call with this LLSession (e.g. with aLAPI_DOCUMENTS created with this LLSession instance) a connection to theserver is opened and then a thread of the LES server is occupied byprocessing the corresponding function.>From the client's perspective this means that you have no way tocheck/test whether there is a free thread on the server. You have toknow.There are several possible techniques to ensure that your applicationdoes not overload the LES server -- the "only one active session" due toglobal synchronization in the client is one approach, but obviously notthe most appealing one. :-)Another approach would be to have a kind of pool of LLSession objects,as much as your LES instance has threads (or the maximum you are willingto grant to the LAPI client). Since you mentioned 4+ users (not hundreds or so), I think yourapplication will not produce heavy load, so you may be fine with asingle LES instance.Of course, the LAPI client/your application compete with any possiblypresent Web-UI users working on this LES instance. (Then I wouldrecommend to deploy one instance as server for the LAPI applicationonly.)

Pfizer_Developers

The documents are exactly the same, except for the name. There is some code in our Livelink instance that gives the document name an incremented number, if the name is the same. Otherwise, the objects are identical.

Thank you very much for your suggestions.