Ok, that's great, now if we can verify the startup cycle of
storeRevisionDescriptors I saw with just a browser is needed for some
reason, we can just watch for unnecessary calls but we don't have to dig
deeper.

Michael Oliver
CTO
Matrix Intermedia Inc.
3325 N. Nellis Blvd, #1
Las Vegas, NV 89115
Phone:(702)643-7425
Fax:(520)844-1036

-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 19, 2004 5:58 AM
To: Slide Developers Mailing List
Subject: Re: Descriptor churn

Yes, you may be right. In 2.0 there could be more requests. I optimized 
this after 2.0...

Oliver

Michael Oliver wrote:

> Yes I expected those, but my impression was that there were at least
> twice that number.  I will verify.
> 
> Michael Oliver
> CTO
> Matrix Intermedia Inc.
> 3325 N. Nellis Blvd, #1
> Las Vegas, NV 89115
> Phone:(702)643-7425
> Fax:(520)844-1036
> 
> -----Original Message-----
> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, July 18, 2004 2:00 PM
> To: Slide Developers Mailing List
> Subject: Re: Descriptor churn
> 
> I can vagualy tell you without experiment:
> 
> - One for the resource
> - One for the collection the resource is in
> - One for the VHR (if autoversioning is turned on and the resource is 
> put under version control with this request)
> - One for the history folder the VHR is in (if autoversioning is
turned
> on)
> - One for the versioned resource in the VHR (if autoversioning is
turned
> on)
> 
> Oliver
> 
> Michael Oliver wrote:
> 
> 
>>I will also have a look at how many storeRevisionDescriptors occur
> 
> with
> 
>>a mkCol or put.
>>
>>Michael Oliver
>>CTO
>>Matrix Intermedia Inc.
>>3325 N. Nellis Blvd, #1
>>Las Vegas, NV 89115
>>Phone:(702)643-7425
>>Fax:(520)844-1036
>>
>>-----Original Message-----
>>From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
>>Sent: Sunday, July 18, 2004 1:44 PM
>>To: Slide Developers Mailing List
>>Subject: Re: Descriptor churn
>>
>>OK, I see. I will have a look at it ASAP.
>>
>>Oliver
>>
>>Michael Oliver wrote:
>>
>>
>>>OZ, I said what I was doing, I was browsing the slide servlet with a
>>
>>web
>>
>>
>>>browser, NOT a Web Folder or a WebDAV client, yet still all those
>>>descriptors were touched.
>>>
>>>Michael Oliver
>>>CTO
>>>Matrix Intermedia Inc.
>>>3325 N. Nellis Blvd, #1
>>>Las Vegas, NV 89115
>>>Phone:(702)643-7425
>>>Fax:(520)844-1036
>>>
>>>-----Original Message-----
>>>From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
>>>Sent: Sunday, July 18, 2004 10:09 AM
>>>To: Slide Developers Mailing List
>>>Subject: Re: Descriptor churn
>>>
>>>As I already said: Which read-only WebDAV methods are being executed 
>>>when storeRevisionDescriptor gets called? If you provide this I
>>
>>promise 
>>
>>
>>>to persue it.
>>>
>>>I would be really surprised if there are modifications inside
>>
>>read-only 
>>
>>
>>>methods, though...
>>>
>>>Oliver
>>>
>>>Michael Oliver wrote:
>>>
>>>
>>>
>>>>That's just it, no WebDAV modifications need be done to see calls to
>>>>storeRevisionDescriptor and here is a test I just ran to show it.
>>>>
>>>>I used a web browser to hit my slide, logged in as root and
navigated
>>>
>>>to
>>>
>>>
>>>
>>>>/files/Matrix and then to /files/Matrix/SalesForce
>>>>
>>>>I went through the logs and storeRevisionDescriptor was called for
> 
> the
> 
>>>>following Uri's:
>>>>
>>>>/
>>>>/users
>>>>/users/[each and every user]
>>>>/roles
>>>>/roles/[each and every role]
>>>>/Actions
>>>>/Actions/[each and every Action]
>>>>/files
>>>>/history
>>>>/workingResource
>>>>
>>>>I verified that all of the xml files from root.def.xml to
>>>>workingResource.def.xml had modified dates corresponding to my
> 
> session
> 
>>>>and there were.
>>>>
>>>>I am glad to hear the transient locks are not persisted, it was a
>>>
>>>guess.
>>>
>>>
>>>
>>>>The above test appears to stop hitting and updating these files
after
>>>>the first pass, but in tracing my own code I have seen
>>>>storeRevisionDescriptor being called on nodes not being modified in
>>>
>>>any
>>>
>>>
>>>
>>>>way when other WebDAV methods are running.
>>>>
>>>>So my conclusion is that there is a flaw, storeRevisionDescriptor is
>>>>being called when nothing in the descriptor has changed or should
>>>
>>>change
>>>
>>>
>>>
>>>>and that is a waste of cycles at best.
>>>>
>>>>Michael Oliver
>>>>CTO
>>>>Matrix Intermedia Inc.
>>>>3325 N. Nellis Blvd, #1
>>>>Las Vegas, NV 89115
>>>>Phone:(702)643-7425
>>>>Fax:(520)844-1036
>>>>
>>>>-----Original Message-----
>>>>From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
>>>>Sent: Saturday, July 17, 2004 1:43 PM
>>>>To: Slide Developers Mailing List
>>>>Subject: Re: Descriptor churn
>>>>
>>>>Hi Michael,
>>>>
>>>>which WebDAV methods are being executed when those 
>>>>storeRevisionDescriptor calls happen?
>>>>
>>>>Most likely, it won't have anything with to do with transient locks
> 
> as
> 
>>>
>>>>they do not get persisted at all.
>>>>
>>>>Oliver
>>>>
>>>>Michael Oliver wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Gents,
>>>>>
>>>>>
>>>>>
>>>>>Reviewing slide logs as much as I do I am seeing a very high number
>>
>>or
>>
>>
>>>>>storeRevisionDescriptor calls when nothing has changed, the user is
>>>>
>>>>just
>>>>
>>>>
>>>>
>>>>
>>>>>navigating around.  If this is resulting in filesystem I/O or
>>
>>database
>>
>>
>>>>>I/O then this seems to be a huge waste of cycles and should be
>>>>
>>>>addressed
>>>>
>>>>
>>>>
>>>>
>>>>>for scalability reasons.  I am presuming this has to do with
>>
>>transient
>>
>>
>>>>>locks but I haven't had the time to research fully.
>>>>>
>>>>>
>>>>>
>>>>>Michael Oliver
>>>>>
>>>>>CTO
>>>>>
>>>>>Matrix Intermedia Inc.
>>>>>
>>>>>3325 N. Nellis Blvd, #1
>>>>>
>>>>>Las Vegas, NV 89115
>>>>>
>>>>>Phone:(702)643-7425
>>>>>
>>>>>Fax:(520)844-1036
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------
-
>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>--------------------------------------------------------------------
-
>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to