chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Hava <brianh...@gmail.com>
Subject Re: Document created but VERY slowly
Date Tue, 23 Oct 2012 20:04:16 GMT
Hi Florian

It looks like there are about 110 properties that come back. One of the properties has over
2100 cmis:choice elements within it. Yikes.

I created a second document with the same object type and it took 2ms!

I'll catch up with you directly about the XML file.

Thanks

On Oct 23, 2012, at 12:45 PM, Florian Müller <fmui@apache.org> wrote:

> Hi Brian,
> 
> That is, the document creation is not the problem. Getting the type definition is the
problem. The type definition is usually pretty small. How many properties are there???
> 
> There is no filter here. You can get the type definition with or without properties,
but not with just a few. In this case, the library needs the property definitions.
> 
> Processing this XML should not take longer than a few seconds (usually it's a matter
of a few milliseconds). But I cannot reproduce it because I don't have a Documentum installation.
Any chance that you can send me the XML directly (not via the list)?
> 
> Just for fun:
> When you create a second document with the same type (and the same session object), how
long does this take?
> The type definition should be cached and creating the second object should be quick.
> 
> 
> Florian
> 
> 
>> Thanks so much for your reply. I'm using the AtomPub binding (sorry
>> for not mentioning that initially).
>> 
>> Looks like when this code executes:
>> 
>> doc = targetFolder.CreateDocument(properties, contentStream, null);
>> 
>> I get the following http requests:
>> GET 15:00:23
>> GMT:/cmis/resources/repositories/[repositoryID]/types/[custom_object_type_id]
>> 
>> POST 15:15:13 GMT:
>> /cmis/resources/repositories/[repositoryID]/objects/0c01ba9d8013677d/children?versioningState=none
>> 
>> The response from the GET is a very large XML file (347K!). In it are
>> all the custom properties and their available values for our custom
>> object type.
>> 
>> I checked with my Documentum support guy, and in the logs he didn't
>> see any activity on the Documentum side during the 15 minute period
>> between the 2 requests. Is it possible that the processing of this
>> large XML file is causing the delay?
>> 
>> I think I've read that there is a properties filter that I can set
>> somewhere before making my request...is that where I could specify the
>> properties I care about, and hopefully reduce the size of that
>> response?
>> 
>> Thanks again for the help.
>> On Oct 19, 2012, at 4:10 AM, Florian Müller  wrote:
>> 
>> Hi Brian,
>> 
>> I have no experiences using DotCMIS with Documentum, but from a
>> DotCMIS perspective the object types doesn't matter. It is just a
>> different string in the XML.
>> Which binding (AtomPub or Web Services) did you use? Can you record
>> the traffic between your application and Documentum (e.g using
>> Fiddler)? Can you see which call is stuck?
>> 
>> Btw. Creating a small document should take far less than a second.
>> Other repositories can create a small text file via CMIS in 100ms.
>> 
>> - Florian
>> 
>> Hi,
>> 
>> I'm using DotCMIS in a C# ASP.net [2] project. I'm trying to create
>> documents in our EMC Documentum repository. I am able to create a very
>> simple text file as a 'cmis:document' very quickly and easily, in a
>> matter of seconds.
>> 
>> When I try to use a document using a custom object type, I can still
>> create a simple text file, but it takes up to *15 minutes*!
>> 
>> I have a colleague who wrote a small app in Java, and when posting
>> the a document using the same custom object type, he gets pretty good
>> performance (3-5 seconds).
>> 
>> I'm entirely new to CMIS in general and am still digging into my code
>> and working with my Documentum support team, but I'm curious if there
>> are any known issues with custom object types in DotCMIS? With DotCMIS
>> and Documentum?
>> 
>> Any insight would be appreciated!
>> 
>> Thanks
>> Brian
>> 
>> 
>> 
>> Links:
>> ------
>> [1] mailto:fmui@apache.org
>> [2] http://ASP.net
> 

Mime
View raw message