[jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
[ https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625281#action_12625281 ] Thilo Goetz commented on UIMA-1129: --- Some things I noticed looking at the patch: * I thought this option would be enabled by a performance tuning option. I don't see that in the patch, maybe I missed it. * There should be a boolean member variable "deltaCasEnabled" or something like that. This should be used in the code for checking this condition, so it's clear what's going on (and easier to change in case the implementation changes). It's also faster. * this.svd.modifiedPreexistingFSs should only be initialised if deltaCasEnabled. We want to keep the CAS reset overhead as small as possible. * There should be no public createMarker() API, see above. * What's the point of having a marker interface if the XmiCasSerializer uses the MarkerImpl? Either make the interface so specific that the XmiCasSerializer can use it, or dispense with the interface altogether. I would vote for not having public interfaces for this. In the CAS you insert a new public API, then say "don't use it". Why? Just keep this implementation internal. > XMI serialization support for delta CAS > - > > Key: UIMA-1129 > URL: https://issues.apache.org/jira/browse/UIMA-1129 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Bhavani Iyer >Assignee: Bhavani Iyer > Attachments: UIMA-1129.patch > > > Extend XMI serialization to enable serializing only the changes to the CAS. > The requirement for delta CAS support in order to to reduce serialization > overhead associated with remote services is described in the wiki page found > here: > http://cwiki.apache.org/UIMA/reducing-overhead-for-remote-service-calls.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
[ https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625520#action_12625520 ] Bhavani Iyer commented on UIMA-1129: [ Show » ] My comments below: Thilo Goetz - 25/Aug/08 01:55 AM Some things I noticed looking at the patch: bq.* I thought this option would be enabled by a performance tuning option. I don't see that in the patch, maybe I missed it. The primary use for this is to enable a serivce to return a delta CAS. The service may reply with a complete CAS or with delta CAS depending on what format the client will accept. So enabling delta CAS is per request and not a global setting. bq.* There should be a boolean member variable "deltaCasEnabled" or something like that. This should be used in the code for checking this condition, so it's clear what's going on (and easier to change in case the implementation changes). The idea here was that the same design initially used to support delta CAS would be used to support journalling as well. When journalling, there will be multiple markers created to track activity per component. bq. It's also faster. Could you please clarify. Are you saying checking a boolean is faster than checking if an object reference is null ? bq.* this.svd.modifiedPreexistingFSs should only be initialised if deltaCasEnabled. We want to keep the CAS reset overhead as small as possible. Good point. Will do. bq.* There should be no public createMarker() API, see above. As explained above, required when a service needs to send a delta cas in the reply to a particular request. bq.* What's the point of having a marker interface if the XmiCasSerializer uses the MarkerImpl? Either make the interface so specific that the XmiCasSerializer can use it, or dispense with the interface altogether. I would vote for not having public interfaces for this. In the CAS you insert a new public API, then say "don't use it". Why? Just keep this implementation internal. There is an example of creating and using the Marker object in the testcase. Applications will use the public interface . In the framework code I used the impl for efficiency . > XMI serialization support for delta CAS > - > > Key: UIMA-1129 > URL: https://issues.apache.org/jira/browse/UIMA-1129 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Bhavani Iyer >Assignee: Bhavani Iyer > Attachments: UIMA-1129.patch > > > Extend XMI serialization to enable serializing only the changes to the CAS. > The requirement for delta CAS support in order to to reduce serialization > overhead associated with remote services is described in the wiki page found > here: > http://cwiki.apache.org/UIMA/reducing-overhead-for-remote-service-calls.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
[ https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625661#action_12625661 ] Thilo Goetz commented on UIMA-1129: --- Bhavani Iyer (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625520#action_12625520 > ] > > Bhavani Iyer commented on UIMA-1129: > > > [ Show » ] > My comments below: > Thilo Goetz - 25/Aug/08 01:55 AM Some things I noticed looking at the patch: > > bq.* I thought this option would be enabled by a performance tuning > option. I don't see that in the patch, maybe I missed it. > > The primary use for this is to enable a serivce to return a delta CAS. > The service may reply with a complete CAS or with delta CAS depending on what > format the client will accept. So enabling delta CAS is per request and > not a global setting. -1. We can't have arbitrary clients turn on Delta CAS mode for everybody else. This must be a global setting. > > bq.* There should be a boolean member variable "deltaCasEnabled" or > something like that. This should be used in the code for checking this > condition, so it's clear what's going on (and easier to change in case the > implementation changes). > >The idea here was that the same design initially used to support delta CAS > would be used to support journalling as well. When journalling, there will > be multiple markers created to track activity per component. So? I don't get your point. > > bq. It's also faster. >Could you please clarify. Are you saying checking a boolean is faster > than checking if an object reference is null ? I think so, though I admit it's only conjecture. > > bq.* this.svd.modifiedPreexistingFSs should only be initialised if > deltaCasEnabled. We want to keep the CAS reset overhead as small as possible. > > Good point. Will do. > > bq.* There should be no public createMarker() API, see above. > >As explained above, required when a service needs to send a delta cas > in the reply to a particular request. > > bq.* What's the point of having a marker interface if the > XmiCasSerializer uses the MarkerImpl? Either make the interface so specific > that the XmiCasSerializer can use it, or dispense with the interface > altogether. I would vote for not having public interfaces for this. In the > CAS you insert a new public API, then say "don't use it". Why? Just keep this > implementation internal. > > There is an example of creating and using the Marker object in the > testcase. Applications will use the public interface . In the framework > code I used the impl for efficiency . If the API is intended to be public, then remove the comment that it's just for framework use. > XMI serialization support for delta CAS > - > > Key: UIMA-1129 > URL: https://issues.apache.org/jira/browse/UIMA-1129 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Bhavani Iyer >Assignee: Bhavani Iyer > Attachments: UIMA-1129.patch > > > Extend XMI serialization to enable serializing only the changes to the CAS. > The requirement for delta CAS support in order to to reduce serialization > overhead associated with remote services is described in the wiki page found > here: > http://cwiki.apache.org/UIMA/reducing-overhead-for-remote-service-calls.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
[
https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625727#action_12625727
]
Eddie Epstein commented on UIMA-1129:
-
{quote}
> bq.* I thought this option would be enabled by a performance tuning option. I
> don't see that in the patch, maybe I missed it.
>
> The primary use for this is to enable a serivce to return a delta CAS. The
> service may reply with a complete CAS or with delta CAS depending on what
> format the client will accept. So enabling delta CAS is per request and not a
> global setting.
-1. We can't have arbitrary clients turn on Delta CAS mode for everybody else.
This must be a global setting.
{quote}
No client turns on delta CAS for any other; each client request must specify
desire for a delta CAS response. A global setting for the service would not
work.
{quote}
> bq.* There should be a boolean member variable "deltaCasEnabled" or something
> like that. This should be used in the code for checking this condition, so
> it's clear what's going on (and easier to change in case the implementation
> changes).
>
> The idea here was that the same design initially used to support delta CAS
> would be used to support journalling as well. When journalling, there will be
> multiple markers created to track activity per component.
So? I don't get your point.
{quote}
I think Bhavani's point is that both CAS and journaling use the marker
mechanism to track CAS activity. Delta CAS is a designed to optimize
client-service overhead. Journaling can be used anywhere, and from a user's
point of view has nothing to do with delta CAS. Instead of
{{monospaced}} "if (this.svd.currentMark != null)" {{monospaced}}
how about using
{{monospaced}} "if (this.svd.casTrackingMark != null)" {{monospaced}}
> XMI serialization support for delta CAS
> -
>
> Key: UIMA-1129
> URL: https://issues.apache.org/jira/browse/UIMA-1129
> Project: UIMA
> Issue Type: New Feature
> Components: Core Java Framework
>Reporter: Bhavani Iyer
>Assignee: Bhavani Iyer
> Attachments: UIMA-1129.patch
>
>
> Extend XMI serialization to enable serializing only the changes to the CAS.
> The requirement for delta CAS support in order to to reduce serialization
> overhead associated with remote services is described in the wiki page found
> here:
> http://cwiki.apache.org/UIMA/reducing-overhead-for-remote-service-calls.html.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
[ https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625762#action_12625762 ] Adam Lally commented on UIMA-1129: -- > -1. We can't have arbitrary clients turn on Delta CAS mode for everybody > else. This must be a global setting. What we want is that when one client turns on delta CAS it does not affect others, but I think that means it must NOT be a global setting. It looks to me like reset() is clearing the mark, so in the case where a client uses the mark and then releases the CAS back to a pool for other clients to use, other clients will not be affected. So I am not sure I see the problem you are objecting to. > > > > bq. It's also faster. > > Could you please clarify. Are you saying checking a boolean is faster than > > checking if an object reference is null ? > I think so, though I admit it's only conjecture. My intuition is that these ought to be the same speed - aren't both just checking a memory location to see if equals some constant value? Without some proof that a boolean check is faster, I'm inclined to say the current implementation is fine. > XMI serialization support for delta CAS > - > > Key: UIMA-1129 > URL: https://issues.apache.org/jira/browse/UIMA-1129 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Bhavani Iyer >Assignee: Bhavani Iyer > Attachments: UIMA-1129.patch > > > Extend XMI serialization to enable serializing only the changes to the CAS. > The requirement for delta CAS support in order to to reduce serialization > overhead associated with remote services is described in the wiki page found > here: > http://cwiki.apache.org/UIMA/reducing-overhead-for-remote-service-calls.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
[ https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626318#action_12626318 ] Eddie Epstein commented on UIMA-1129: - Bhavani, Your UIMA-1129-1.patch is committed. The issue needs to stay open until appropriate documentation changes are done, for example, in "Chapter 7. XMI CAS Serialization Reference." Can you either point us at the new format details, or if not there add the details to this issue (or even modify the reference document itself :)? Thanks, Eddie > XMI serialization support for delta CAS > - > > Key: UIMA-1129 > URL: https://issues.apache.org/jira/browse/UIMA-1129 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Bhavani Iyer >Assignee: Bhavani Iyer > Attachments: UIMA-1129-1.patch, UIMA-1129.patch > > > Extend XMI serialization to enable serializing only the changes to the CAS. > The requirement for delta CAS support in order to to reduce serialization > overhead associated with remote services is described in the wiki page found > here: > http://cwiki.apache.org/UIMA/reducing-overhead-for-remote-service-calls.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
[ https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633716#action_12633716 ] Eddie Epstein commented on UIMA-1129: - There appears to be a bug on delta CAS serialization for content added to a named view. For my scenario under test, the input CAS to a service has a single, named view. The service adds FS to that view, but the delta CAS output assigns all the new content to _InitialView. Probably related, according to a Cas dump done from inside the service, the _InitialView is created during service processing, although it has no content. > XMI serialization support for delta CAS > - > > Key: UIMA-1129 > URL: https://issues.apache.org/jira/browse/UIMA-1129 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Bhavani Iyer >Assignee: Bhavani Iyer > Attachments: UIMA-1129-1.patch, UIMA-1129-2.patch, > UIMA-1129-2a.patch, UIMA-1129-3.patch, UIMA-1129.patch > > > Extend XMI serialization to enable serializing only the changes to the CAS. > The requirement for delta CAS support in order to to reduce serialization > overhead associated with remote services is described in the wiki page found > here: > http://cwiki.apache.org/UIMA/reducing-overhead-for-remote-service-calls.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
Eddie Epstein (JIRA) wrote:
> [
> https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625727#action_12625727
> ]
>
> Eddie Epstein commented on UIMA-1129:
> -
>
> {quote}
>> bq.* I thought this option would be enabled by a performance tuning option.
>> I don't see that in the patch, maybe I missed it.
>>
>> The primary use for this is to enable a serivce to return a delta CAS. The
>> service may reply with a complete CAS or with delta CAS depending on what
>> format the client will accept. So enabling delta CAS is per request and not
>> a global setting.
>
> -1. We can't have arbitrary clients turn on Delta CAS mode for everybody
> else. This must be a global setting.
> {quote}
>
> No client turns on delta CAS for any other; each client request must specify
> desire for a delta CAS response. A global setting for the service would not
> work.
Not sure we're talking about the same thing. I mean that the delta CAS mode
must
be enabled by the app, and can't be enabled by an annotator.
>
> {quote}
>> bq.* There should be a boolean member variable "deltaCasEnabled" or
>> something like that. This should be used in the code for checking this
>> condition, so it's clear what's going on (and easier to change in case the
>> implementation changes).
>>
>> The idea here was that the same design initially used to support delta CAS
>> would be used to support journalling as well. When journalling, there will
>> be multiple markers created to track activity per component.
>
> So? I don't get your point.
> {quote}
>
> I think Bhavani's point is that both CAS and journaling use the marker
> mechanism to track CAS activity. Delta CAS is a designed to optimize
> client-service overhead. Journaling can be used anywhere, and from a user's
> point of view has nothing to do with delta CAS. Instead of
> {{monospaced}} "if (this.svd.currentMark != null)" {{monospaced}}
> how about using
> {{monospaced}} "if (this.svd.casTrackingMark != null)" {{monospaced}}
I still don't understand, but I get the feeling that it's not important.
>
>
>
>> XMI serialization support for delta CAS
>> -
>>
>> Key: UIMA-1129
>> URL: https://issues.apache.org/jira/browse/UIMA-1129
>> Project: UIMA
>> Issue Type: New Feature
>> Components: Core Java Framework
>>Reporter: Bhavani Iyer
>>Assignee: Bhavani Iyer
>> Attachments: UIMA-1129.patch
>>
>>
>> Extend XMI serialization to enable serializing only the changes to the CAS.
>> The requirement for delta CAS support in order to to reduce serialization
>> overhead associated with remote services is described in the wiki page found
>> here:
>> http://cwiki.apache.org/UIMA/reducing-overhead-for-remote-service-calls.html.
>
Re: [jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
Thilo Goetz <[EMAIL PROTECTED]> wrote: > > > > No client turns on delta CAS for any other; each client request must > specify desire for a delta CAS response. A global setting for the service > would not work. > > Not sure we're talking about the same thing. I mean that the delta CAS > mode must > be enabled by the app, and can't be enabled by an annotator. > Ah, of course. That is already in the patch code.
Re: [jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
Something went wrong with the patch diff. It is showing every line as "changed". This sometimes happens when the files don't have the right svn property set for line endings. The result is we lose the ability to easily see what was changed in the commit log. -Marshall Eddie Epstein (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626318#action_12626318 > ] > > Eddie Epstein commented on UIMA-1129: > - > > Bhavani, > > Your UIMA-1129-1.patch is committed. The issue needs to stay open until > appropriate documentation changes are done, for example, in "Chapter 7. XMI > CAS Serialization Reference." > > Can you either point us at the new format details, or if not there add the > details to this issue (or even modify the reference document itself :)? > > Thanks, > Eddie > > >> XMI serialization support for delta CAS >> - >> >> Key: UIMA-1129 >> URL: https://issues.apache.org/jira/browse/UIMA-1129 >> Project: UIMA >> Issue Type: New Feature >> Components: Core Java Framework >>Reporter: Bhavani Iyer >>Assignee: Bhavani Iyer >> Attachments: UIMA-1129-1.patch, UIMA-1129.patch >> >> >> Extend XMI serialization to enable serializing only the changes to the CAS. >> The requirement for delta CAS support in order to to reduce serialization >> overhead associated with remote services is described in the wiki page found >> here: >> http://cwiki.apache.org/UIMA/reducing-overhead-for-remote-service-calls.html. >> > >
Re: [jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
On Wed, Aug 27, 2008 at 5:11 PM, Marshall Schor <[EMAIL PROTECTED]> wrote: > Something went wrong with the patch diff. It is showing every line as > "changed". This sometimes happens when the files don't have the right > svn property set for line endings. The result is we lose the ability to > easily see what was changed in the commit log. > > -Marshall > Using eclipse to compare XmiCasDeserializerTest.java against the previous revision showed selected lines changed, even though the email showed every line changed. Maybe we are ok? Eddie
Re: [jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
On Wed, Aug 27, 2008 at 5:11 PM, Marshall Schor <[EMAIL PROTECTED]> wrote: > Something went wrong with the patch diff. It is showing every line as > "changed". This sometimes happens when the files don't have the right > svn property set for line endings. The result is we lose the ability to > easily see what was changed in the commit log. > > -Marshall > Using eclipse to compare XmiCasDeserializerTest.java against the previous revision showed selected lines changed, even though the email showed every line changed. Maybe we are ok? Eddie
Re: [jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
Looks OK to me ... many lines added but few deleted.
Re: [jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
Spoke too soon ... I was looking at the patch itself. When running svn diff on the last change I also see every line changed ... caused by the native lineends as mylatest copy is now a DOS file. Has the eol-style been changed already? On Thu, Aug 28, 2008 at 10:50 AM, Burn Lewis <[EMAIL PROTECTED]> wrote: > Looks OK to me ... many lines added but few deleted. > >
