Re: Using Delta CAS serialization in UIMA-AS
On Wed, Aug 27, 2008 at 4:47 PM, Marshall Schor <[EMAIL PROTECTED]> wrote: > Bhavani Iyer wrote: >> Now that we have Delta CAS support, can we use it in UIMA-AS ? >> I'm planning to make the modifications to use Delta CAS as follows. >> Please add your comments/suggestions. >> >> *Additional Properties in the ProcessCAS message:* >> > For these new things, is there anything in the proposed OASIS spec which > we could be following? The OASIS spec just says that a service may reply with a delta, it doesn't provide for a client requesting whether it wants a delta or not. I don't think it prohibits a service from having an additional variation of the ProcessCAS operation that takes additional arguments such as Bhavani has suggested. Those arguments would just need to be optional so that a client that was unaware of them could still interact with the service. >> There will be an additional property, *AcceptsDeltaCas*, in the ProcessCAS >> request message sent by a UIMA-AS client (including a UIMA-AS aggregate that >> calls a remote delegate) to a service specifying that the client accepts a >> Delta CAS in the reply. The boolean property will default to true. >> > Not sure what is meant by "default". Can you elaborate? > If an older client (pre delta cas) connects to a newer service - this > probably should "work" (unless there are other things preventing it). I share Marshall's confusion. From the service's perspective, I think the default for AcceptsDeltaCas is false. If it is not set, the service won't reply with a delta, thus supporting older clients. Bhavani might have meant a different meaning for "default" - that a new client will always send a value of true unless otherwise configured (which I think is fine). >> *Parallel Step handling* >> The parallel step contract requires that the remote delegates called in >> parallel only >> create new FSs. >> >> Currently, since the complete CAS is serialized and sent in the reply >> message, >> pre-existing FSs are ignored during deserialization. >> >> With Delta CAS, its now possible to enforce the parallel step contract by >> specifying the option to disallow pre-existing FS when deserializing. >> Should we do this ? >> > I think yes, because it helps produce results for users which are more > dependable. I agree that if we have the contract and can enforce it, we should. But alternatively, could we relax this parallel step contract when delta CAS is in use? The prior implementation of parallel step had no good way of recognizing when a modification of a pre-existing FS had taken place. But with delta CAS, now it does, so it could apply those changes back to the common CAS. Of course, if two services modify the same feature in different ways, then we'd have a conflict. We could detect this and throw an exception. This would allow the use of updates of different parts of a CAS in a parallel step, and only fail when common data is modified. So it allows more flexibility at the cost of giving the user more ways to get themselves into trouble. Maybe it's not worth it. >> Note that there could be mix of older and newer services called >> in the parallel step. The older serivces will reply with the complete CAS. >> In this >> case, pre-existing FSs will be ignored as they are being done currently. >> * >> Disabling Delta CAS reply* >> It may be necessary to require a service to always serialize >> and reply with the complete CAS. This may be required for debugging >> or to work around Delta CAS limitations. To specify this, a parameter >> is required in the deployment descriptor. >> > Not sure the deployment descriptor is the best place for this. We don't > put other "debugging" info here. What other choices exist for > specifying this? JVM System property? others? > Bhavani, could you say more about in what scenarios you imagine someone would need to disable the delta cas response? If it's really only for debugging, then I agree with Marshall - make it a system property if you need it. If there might actually be a time when delta CAS needs to be turned off in a production system, then it belongs in the deployment descriptor. -Adam
[jira] Updated: (UIMA-1158) Some shell scripts don't work on Ubuntu Linux
[ https://issues.apache.org/jira/browse/UIMA-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Burn Lewis updated UIMA-1158: - Attachment: UIMA-1158-core.patch UIMA-1158-as.patch These fix the shell scripts in uima-as and in core uima by removing any bashisms ... should now run under POSIX shells such as dash. > Some shell scripts don't work on Ubuntu Linux > - > > Key: UIMA-1158 > URL: https://issues.apache.org/jira/browse/UIMA-1158 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.2.2 >Reporter: Burn Lewis > Attachments: UIMA-1158-as.patch, UIMA-1158-core.patch > > > Ubuntu uses /bin/dash as the default shell and we have some bashisms in ours, > e.g. in startBroker.sh. > Simplest fix is probably to change #!/bin/sh to #!/bin/bash -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Using Delta CAS serialization in UIMA-AS
On Wed, Aug 27, 2008 at 4:47 PM, Marshall Schor <[EMAIL PROTECTED]> wrote: > > > Bhavani Iyer wrote: > > Now that we have Delta CAS support, can we use it in UIMA-AS ? > > I'm planning to make the modifications to use Delta CAS as follows. > > Please add your comments/suggestions. > > > > *Additional Properties in the ProcessCAS message:* > > There will be an additional property, *AcceptsDeltaCas*, in the > ProcessCAS > > request message sent by a UIMA-AS client (including a UIMA-AS aggregate > that > > calls a remote delegate) to a service specifying that the client accepts > a > > Delta CAS in the reply. The boolean property will default to true. > > > Not sure what is meant by "default". Can you elaborate? > If an older client (pre delta cas) connects to a newer service - this > probably should "work" (unless there are other things preventing it). Newer clients will by default have the property, AcceptsDeltaCAS, set to 'true' in the request message. This default setting implies newer services will by default reply to newer clients with a Delta CAS . If we want to support newer clients requiring a complete CAS in the reply, the value of this property would have to be set to false or not set at all . If we want to allow this, we would have to provide a mechanism to specify this. Newer services will check the property AcceptsDeltaCAS and if available and set to true will send a reply message containing a Delta CAS and with the new property SentDeltaCas set to true. A newer service may ignore this property and reply with a complete CAS if the service has been configured to always reply with a completeCAS (see Disablisng Delta CAS below). In this case the property SentDeltaCAS will be set to false (or we can omit it in the reply message). Newer clients will check the property, SentDeltaCAS. A DeltaCAS deserialization is done if this property is available and set to true in the reply message. > *Parallel Step handling*> > > With Delta CAS, its now possible to enforce the parallel step contract by > > specifying the option to disallow pre-existing FS when deserializing. > > Should we do this ? > > > I think yes, because it helps produce results for users which are more > dependable. OK. > > > > > > > > >
Setting eol-style:native for uima source (not test data) files
Any objections to setting this on the main uima project? I set it on the uima-as project some time ago, and haven't had any issues. This would be only on the source files, since some of the test data needs different kinds of line endings. -Marshall
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. >> > >
[jira] Commented: (UIMA-1110) The default setting of prefetch=1 is causing problems
[ https://issues.apache.org/jira/browse/UIMA-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626322#action_12626322 ] Marshall Schor commented on UIMA-1110: -- Also, see UIMA-1059 - which was closed with won't fix, to be considered with this Jira instead. (Issue in 1059 was to update dd2spring to disallow setting prefetch on inner aggregates). If we go with alternative 3, which is the one suggesting prefetch should be associated with remote delegates, I think the current syntax for prefetch (which is to put it as an attribute on the inputQueue element) is confusing - since it has nothing here to do with the remote delegate's input queue. Instead, it could be treated more like we did the additional tuning attributes for remoteReplyQueueScaleout. I agree the top level prefetch should not be used to set the prefetch for everything. The prefetch for the free CAS Q for a cas multiplier = 10 is a good example. What about Alternative 4: setting prefetch for the top level queue via the deployment descriptor arg, but then having the the others work as Alternative 3? As I recall, the remoteReplyQueueScaleout - which could be used to make more threads available for reading the reply q - was thought to be an alternative to setting the prefetch for the remote reply queue above 0. > The default setting of prefetch=1 is causing problems > - > > Key: UIMA-1110 > URL: https://issues.apache.org/jira/browse/UIMA-1110 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Eddie Epstein >Assignee: Eddie Epstein > > The new JMX monitor occasionally shows idle times of many seconds for a > scaled out remote delegate that is getting many CASes per second. Assuming > the monitor is correct, the problem is that AMQ is not evenly distributing > the work to all the service instances. Other recent experiences have > demonstrated that uneven distribution is solved with prefetch=0. > While there is some possibility that prefetch > 0 may be useful in some > situations for remote delegates, for colocated delegates there is little > doubt that a prefetch greater than 0 cannot help performance and can only > screw up load balancing. > prefetch=0 should be the default everywhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1059) dd2spring doesn't reject the prefetch attribute on the inputQueue for a remore delegate
[ https://issues.apache.org/jira/browse/UIMA-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1059. Resolution: Won't Fix Won't fix on this Jira, consolidate with UIMA-1110 > dd2spring doesn't reject the prefetch attribute on the inputQueue for a > remore delegate > --- > > Key: UIMA-1059 > URL: https://issues.apache.org/jira/browse/UIMA-1059 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Burn Lewis >Priority: Minor > > prefetch is relevant only for the inputQueue when deploying a service ... not > when specifying remote delegates. > Currently dd2spring quietly ignores it when on a remote delegate's queue ... > any chance it can report this as an error? -- 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.
Re: Using Delta CAS serialization in UIMA-AS
Bhavani Iyer wrote: > Now that we have Delta CAS support, can we use it in UIMA-AS ? > I'm planning to make the modifications to use Delta CAS as follows. > Please add your comments/suggestions. > > *Additional Properties in the ProcessCAS message:* > For these new things, is there anything in the proposed OASIS spec which we could be following? > There will be an additional property, *AcceptsDeltaCas*, in the ProcessCAS > request message sent by a UIMA-AS client (including a UIMA-AS aggregate that > calls a remote delegate) to a service specifying that the client accepts a > Delta CAS in the reply. The boolean property will default to true. > Not sure what is meant by "default". Can you elaborate? If an older client (pre delta cas) connects to a newer service - this probably should "work" (unless there are other things preventing it). > A new boolean property in the ProcessCAS reply message, *SentDeltaCas*, is > required which indicates that the service sent a Delta CAS in the reply. > > These two properties will enable older UIMA-AS clients and services to work > with newer client and service. > > *Parallel Step handling* > The parallel step contract requires that the remote delegates called in > parallel only > create new FSs. > > Currently, since the complete CAS is serialized and sent in the reply > message, > pre-existing FSs are ignored during deserialization. > > With Delta CAS, its now possible to enforce the parallel step contract by > specifying the option to disallow pre-existing FS when deserializing. > Should we do this ? > I think yes, because it helps produce results for users which are more dependable. > Note that there could be mix of older and newer services called > in the parallel step. The older serivces will reply with the complete CAS. > In this > case, pre-existing FSs will be ignored as they are being done currently. > * > Disabling Delta CAS reply* > It may be necessary to require a service to always serialize > and reply with the complete CAS. This may be required for debugging > or to work around Delta CAS limitations. To specify this, a parameter > is required in the deployment descriptor. > Not sure the deployment descriptor is the best place for this. We don't put other "debugging" info here. What other choices exist for specifying this? JVM System property? others? Thanks for making progress here :-) -Marshall > Thanks, > Bhavani > >
Using Delta CAS serialization in UIMA-AS
Now that we have Delta CAS support, can we use it in UIMA-AS ? I'm planning to make the modifications to use Delta CAS as follows. Please add your comments/suggestions. *Additional Properties in the ProcessCAS message:* There will be an additional property, *AcceptsDeltaCas*, in the ProcessCAS request message sent by a UIMA-AS client (including a UIMA-AS aggregate that calls a remote delegate) to a service specifying that the client accepts a Delta CAS in the reply. The boolean property will default to true. A new boolean property in the ProcessCAS reply message, *SentDeltaCas*, is required which indicates that the service sent a Delta CAS in the reply. These two properties will enable older UIMA-AS clients and services to work with newer client and service. *Parallel Step handling* The parallel step contract requires that the remote delegates called in parallel only create new FSs. Currently, since the complete CAS is serialized and sent in the reply message, pre-existing FSs are ignored during deserialization. With Delta CAS, its now possible to enforce the parallel step contract by specifying the option to disallow pre-existing FS when deserializing. Should we do this ? Note that there could be mix of older and newer services called in the parallel step. The older serivces will reply with the complete CAS. In this case, pre-existing FSs will be ignored as they are being done currently. * Disabling Delta CAS reply* It may be necessary to require a service to always serialize and reply with the complete CAS. This may be required for debugging or to work around Delta CAS limitations. To specify this, a parameter is required in the deployment descriptor. Thanks, Bhavani
[jira] Commented: (UIMA-1059) dd2spring doesn't reject the prefetch attribute on the inputQueue for a remore delegate
[ https://issues.apache.org/jira/browse/UIMA-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626302#action_12626302 ] Eddie Epstein commented on UIMA-1059: - This may not be an error as one of the alternatives in UIMA-1110 is to allow prefetch customization for a remote delegate's queue. I suggest closing this issue and moving the discussion to 1110. > dd2spring doesn't reject the prefetch attribute on the inputQueue for a > remore delegate > --- > > Key: UIMA-1059 > URL: https://issues.apache.org/jira/browse/UIMA-1059 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Burn Lewis >Priority: Minor > > prefetch is relevant only for the inputQueue when deploying a service ... not > when specifying remote delegates. > Currently dd2spring quietly ignores it when on a remote delegate's queue ... > any chance it can report this as an error? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Accept CAS Viewer source code into the sandbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eddie Epstein wrote: > With the following understanding: > > "We should > decide on one tool as the basis for viewing and editing > CASes. As we have already released the CAS Editor, it should > be that one tool. We should vote the CasViewer into the > sandbox with the express understanding that it will never > see a release, but ideas and code from the CasViewer will > be used to improve and enhance the CAS Editor. The CAS > Editor will evolve into a tool that can be used either > stand-alone (as it is now), or integrated into the rest > of the UIMA tooling." > > Please cast your vote: > > [ ] +1 accept CAS viewer source code into sandbox > [ ] 0 don't care > [ ] -1 don't accept, I still have issues > > Thanks, Eddie > +1 - --Thilo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIta6NVCINLMh0FVwRAt0tAJ9TQ/m8k0fFVC7iP44l3LIbeL9xXQCffmJo apmNxOvu1TkRmcZP4tSj+70= =wv8s -END PGP SIGNATURE-
Using Delta CAS serialization in UIMA-AS
Now that we have Delta CAS support, can we use it in UIMA-AS ? I'm planning to make the modifications to use Delta CAS as follows. Please add your comments/suggestions. *Additional Properties in the ProcessCAS message:* There will be an additional property, *AcceptsDeltaCas*, in the ProcessCAS request message sent by a UIMA-AS client (including a UIMA-AS aggregate that calls a remote delegate) to a service specifying that the client accepts a Delta CAS in the reply. The boolean property will default to true. A new boolean property in the ProcessCAS reply message, *SentDeltaCas*, is required which indicates that the service sent a Delta CAS in the reply. These two properties will enable older UIMA-AS clients and services to work with newer client and service. *Parallel Step handling* The parallel step contract requires that the remote delegates called in parallel only create new FSs. Currently, since the complete CAS is serialized and sent in the reply message, pre-existing FSs are ignored during deserialization. With Delta CAS, its now possible to enforce the parallel step contract by specifying the option to disallow pre-existing FS when deserializing. Should we do this ? Note that there could be mix of older and newer services called in the parallel step. The older serivces will reply with the complete CAS. In this case, pre-existing FSs will be ignored as they are being done currently. * Disabling Delta CAS reply* It may be necessary to require a service to always serialize and reply with the complete CAS. This may be required for debugging or to work around Delta CAS limitations. To specify this, a parameter is required in the deployment descriptor. Thanks, Bhavani
[jira] Updated: (UIMA-1136) [DDE] Support editing of Prefetch value and set default value to 0 (instead of 1)
[ https://issues.apache.org/jira/browse/UIMA-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tong Fin updated UIMA-1136: --- Attachment: screenshot-1.jpg The UI of updating "prefetch" value (default is 0) > [DDE] Support editing of Prefetch value and set default value to 0 (instead > of 1) > - > > Key: UIMA-1136 > URL: https://issues.apache.org/jira/browse/UIMA-1136 > Project: UIMA > Issue Type: Improvement > Components: Async Scaleout >Reporter: Tong Fin >Assignee: Tong Fin >Priority: Trivial > Fix For: 2.3AS > > Attachments: DDE_Patch_1of2_JIRA-1136.txt, > DDE_Patch_2of2_JIRA-1136.txt, screenshot-1.jpg > > > For the current version of DDE, to change the value of the "Prefetch" of the > Top AE, the user needs to modify the value in the "source" XML. Until now, > the default value is set to "1". > We will modify the DDE as follows: > 1. Allow user to modify the prefetch value with GUI (in the 1st page of DDE) > 2. Set the default value to 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1136) [DDE] Support editing of Prefetch value and set default value to 0 (instead of 1)
[ https://issues.apache.org/jira/browse/UIMA-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tong Fin reassigned UIMA-1136: -- Assignee: Marshall Schor (was: Tong Fin) Marshall, Pls help to apply the patch (2 files). -- Tong > [DDE] Support editing of Prefetch value and set default value to 0 (instead > of 1) > - > > Key: UIMA-1136 > URL: https://issues.apache.org/jira/browse/UIMA-1136 > Project: UIMA > Issue Type: Improvement > Components: Async Scaleout >Reporter: Tong Fin >Assignee: Marshall Schor >Priority: Trivial > Fix For: 2.3AS > > Attachments: DDE_Patch_1of2_JIRA-1136.txt, > DDE_Patch_2of2_JIRA-1136.txt, screenshot-1.jpg > > > For the current version of DDE, to change the value of the "Prefetch" of the > Top AE, the user needs to modify the value in the "source" XML. Until now, > the default value is set to "1". > We will modify the DDE as follows: > 1. Allow user to modify the prefetch value with GUI (in the 1st page of DDE) > 2. Set the default value to 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1136) [DDE] Support editing of Prefetch value and set default value to 0 (instead of 1)
[ https://issues.apache.org/jira/browse/UIMA-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tong Fin updated UIMA-1136: --- Attachment: DDE_Patch_2of2_JIRA-1136.txt DDE_Patch_1of2_JIRA-1136.txt > [DDE] Support editing of Prefetch value and set default value to 0 (instead > of 1) > - > > Key: UIMA-1136 > URL: https://issues.apache.org/jira/browse/UIMA-1136 > Project: UIMA > Issue Type: Improvement > Components: Async Scaleout >Reporter: Tong Fin >Assignee: Tong Fin >Priority: Trivial > Fix For: 2.3AS > > Attachments: DDE_Patch_1of2_JIRA-1136.txt, > DDE_Patch_2of2_JIRA-1136.txt > > > For the current version of DDE, to change the value of the "Prefetch" of the > Top AE, the user needs to modify the value in the "source" XML. Until now, > the default value is set to "1". > We will modify the DDE as follows: > 1. Allow user to modify the prefetch value with GUI (in the 1st page of DDE) > 2. Set the default value to 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1135) UIMA-AS dd2spring needs update for UIMA-1019
[ https://issues.apache.org/jira/browse/UIMA-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1135. Resolution: Fixed Fix Version/s: 2.3AS > UIMA-AS dd2spring needs update for UIMA-1019 > > > Key: UIMA-1135 > URL: https://issues.apache.org/jira/browse/UIMA-1135 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.2.2AS >Reporter: Marshall Schor >Priority: Trivial > Fix For: 2.3AS > > > The uima-1019 issue changed the way remote cas multiplier queues were managed. > In particular, uima-1019: > Modified UIMA-AS to support Aggregate CM. As part of this enhancement, also > modified the client code to support remote CM. Each remote CM instance ( > primitive or aggregate) creates its own Temp FCQ( Free CAS Queue) for > receiving notifications from a client. This notification enables the CM to > release the next CAS and send another to a client. Scaleout of Remote CM is > also supported now. > and > Added support for Aggregate CAS Multipliers. Based on OperationalProperties > an Aggregate UIMA-As may output CASes to its client. The Aggregate CM creates > a special temp queue for receiving Free CAS requests from a client. > dd2spring.xsl needs updating to align with this new approach; there are beans > it generates which are no longer used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-275) C++: Rework documentation for first release
[ https://issues.apache.org/jira/browse/UIMA-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eddie Epstein closed UIMA-275. -- Resolution: Fixed > C++: Rework documentation for first release > --- > > Key: UIMA-275 > URL: https://issues.apache.org/jira/browse/UIMA-275 > Project: UIMA > Issue Type: Bug > Components: C++ Framework >Affects Versions: 2.1 >Reporter: Eddie Epstein >Assignee: Eddie Epstein > Fix For: 2.2C > > > Eliminate Quickstart and rework for SDK documentation. Expand material on > building and testing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1064) Clarify uimacpp build environment and dependencies
[ https://issues.apache.org/jira/browse/UIMA-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eddie Epstein closed UIMA-1064. --- Resolution: Fixed > Clarify uimacpp build environment and dependencies > -- > > Key: UIMA-1064 > URL: https://issues.apache.org/jira/browse/UIMA-1064 > Project: UIMA > Issue Type: Bug > Components: C++ Framework >Reporter: Eddie Epstein >Assignee: Eddie Epstein > Fix For: 2.2C > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1143) Fix problems identified with copyright and notice
[ https://issues.apache.org/jira/browse/UIMA-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eddie Epstein closed UIMA-1143. --- Resolution: Fixed > Fix problems identified with copyright and notice > - > > Key: UIMA-1143 > URL: https://issues.apache.org/jira/browse/UIMA-1143 > Project: UIMA > Issue Type: Bug > Components: C++ Framework >Reporter: Eddie Epstein >Assignee: Eddie Epstein > Fix For: 2.2C > > > For details, see discussion in uima-dev related to subject "[VOTE] Release > uimacpp-2.2.2-02 as uimacpp-2.2.2-incubating" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Accept CAS Viewer source code into the sandbox
Eddie Epstein wrote: > With the following understanding: > > "We should > decide on one tool as the basis for viewing and editing > CASes. As we have already released the CAS Editor, it should > be that one tool. We should vote the CasViewer into the > sandbox with the express understanding that it will never > see a release, but ideas and code from the CasViewer will > be used to improve and enhance the CAS Editor. The CAS > Editor will evolve into a tool that can be used either > stand-alone (as it is now), or integrated into the rest > of the UIMA tooling." > > Please cast your vote: > > [ ] +1 accept CAS viewer source code into sandbox > [ ] 0 don't care > [ ] -1 don't accept, I still have issues > > Thanks, Eddie > > +1 Marshall
[jira] Closed: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tong Fin closed UIMA-1146. -- Verified > Setting the number of concurrent listeners of a reply queue for Co-located > Delegates > > > Key: UIMA-1146 > URL: https://issues.apache.org/jira/browse/UIMA-1146 > Project: UIMA > Issue Type: Improvement > Components: Async Scaleout >Affects Versions: 2.2.2AS >Reporter: Tong Fin >Assignee: Tong Fin > Fix For: 2.3AS > > Attachments: DDE_Patch_1of2_JIRA-1146.txt, > DDE_Patch_2of2Modified08-25-2008_JIRA-1146.txt, queue-listeners.jpg > > > JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent > listeners of a reply queue for each "remote" delegate. The following is the > syntax in the xml deployment descriptor (as an example): > > > > endpoint="RoomNumberAnnotatorQueue"/> > > ... > > > ... > > This JIRA will do the similar thing by allowing users to set the number of > concurrent listeners of a reply queue for "co-located" delegates inside the > UIMA-AS aggregate. > The following is the "proposed" syntax: > > > ... > > > > ... > > ... > > ... > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Accept CAS Viewer source code into the sandbox
On Wed, Aug 27, 2008 at 10:08 AM, Eddie Epstein <[EMAIL PROTECTED]> wrote: > With the following understanding: > > "We should > decide on one tool as the basis for viewing and editing > CASes. As we have already released the CAS Editor, it should > be that one tool. We should vote the CasViewer into the > sandbox with the express understanding that it will never > see a release, but ideas and code from the CasViewer will > be used to improve and enhance the CAS Editor. The CAS > Editor will evolve into a tool that can be used either > stand-alone (as it is now), or integrated into the rest > of the UIMA tooling." > > Please cast your vote: > > [ ] +1 accept CAS viewer source code into sandbox > [ ] 0 don't care > [ ] -1 don't accept, I still have issues > > Thanks, Eddie > +1 -Adam
[jira] Closed: (UIMA-1161) UIMA-AS inputQueueScaleout should be settable on nested co-located aggregates
[ https://issues.apache.org/jira/browse/UIMA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1161. Resolution: Fixed Fix Version/s: 2.3AS > UIMA-AS inputQueueScaleout should be settable on nested co-located aggregates > - > > Key: UIMA-1161 > URL: https://issues.apache.org/jira/browse/UIMA-1161 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.3AS > > > My initial thinking about this reasoned that for co-located nested > aggregates, their input queues would not need any scaleout because there > would be no deserialization (the input queue passes a handle instead of a > serialized CAS for co-located nested aggregates). And also, no > re-serialization back to the invoker (again, just a handle is passed). > However, Eddie has pointed out that if the nested aggregate has a remote > delegate as its first component, then the serialization work going to that > delegate is done using the thread on the input queue listener. > Also, I note that if the flow controller work requires any significant time, > scaleout might be needed, as the input queue listener thread is used for the > first entry into the flow controller (subsequent entries into the flow > controller run on the aggregate's reply queue listeners). > Because of this, we should allow the inputQueueScaleout parameter on nested > aggregates, as well as just on the top level one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1161) UIMA-AS inputQueueScaleout should be settable on nested co-located aggregates
UIMA-AS inputQueueScaleout should be settable on nested co-located aggregates - Key: UIMA-1161 URL: https://issues.apache.org/jira/browse/UIMA-1161 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor My initial thinking about this reasoned that for co-located nested aggregates, their input queues would not need any scaleout because there would be no deserialization (the input queue passes a handle instead of a serialized CAS for co-located nested aggregates). And also, no re-serialization back to the invoker (again, just a handle is passed). However, Eddie has pointed out that if the nested aggregate has a remote delegate as its first component, then the serialization work going to that delegate is done using the thread on the input queue listener. Also, I note that if the flow controller work requires any significant time, scaleout might be needed, as the input queue listener thread is used for the first entry into the flow controller (subsequent entries into the flow controller run on the aggregate's reply queue listeners). Because of this, we should allow the inputQueueScaleout parameter on nested aggregates, as well as just on the top level one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1129) XMI serialization support for delta CAS
[ https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavani Iyer updated UIMA-1129: --- Attachment: UIMA-1129-1.patch This patch replaces the previous patch. It includes modifications made to address issues with the previous patch: - modifiedPreexisitngFS is initialized only when trackingMark is set. - renamed currentMark variable to trackingMark. - fixed javadoc comments. > 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.
Re: [VOTE] Accept CAS Viewer source code into the sandbox
"We should decide on one tool as the basis for viewing and editing CASes. As we have already released the CAS Editor, it should be that one tool. We should vote the CasViewer into the sandbox with the express understanding that it will never see a release, but ideas and code from the CasViewer will be used to improve and enhance the CAS Editor. The CAS Editor will evolve into a tool that can be used either stand-alone (as it is now), or integrated into the rest of the UIMA tooling." Please cast your vote: [ ] +1 accept CAS viewer source code into sandbox [ ] 0 don't care [ ] -1 don't accept, I still have issues +1
[jira] Closed: (UIMA-1159) UIMA-AS dd2Spring fix - generating wrong property for co-located component - treating it as a remote
[ https://issues.apache.org/jira/browse/UIMA-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1159. Resolution: Fixed actually only 7 expected results. all fixed. > UIMA-AS dd2Spring fix - generating wrong property for co-located component - > treating it as a remote > > > Key: UIMA-1159 > URL: https://issues.apache.org/jira/browse/UIMA-1159 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.2.2AS >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 2.3AS > > > The property "tempReplyDestination" is being set to "true" for co located > components - this should not be set for these. > Bug introduced with previous fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-1159) UIMA-AS dd2Spring fix - generating wrong property for co-located component - treating it as a remote
[ https://issues.apache.org/jira/browse/UIMA-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reopened UIMA-1159: -- Forgot to fix the 8 test cases that were affected by this change. > UIMA-AS dd2Spring fix - generating wrong property for co-located component - > treating it as a remote > > > Key: UIMA-1159 > URL: https://issues.apache.org/jira/browse/UIMA-1159 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.2.2AS >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 2.3AS > > > The property "tempReplyDestination" is being set to "true" for co located > components - this should not be set for these. > Bug introduced with previous fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Accept CAS Viewer source code into the sandbox
With the following understanding: "We should decide on one tool as the basis for viewing and editing CASes. As we have already released the CAS Editor, it should be that one tool. We should vote the CasViewer into the sandbox with the express understanding that it will never see a release, but ideas and code from the CasViewer will be used to improve and enhance the CAS Editor. The CAS Editor will evolve into a tool that can be used either stand-alone (as it is now), or integrated into the rest of the UIMA tooling." Please cast your vote: [ ] +1 accept CAS viewer source code into sandbox [ ] 0 don't care [ ] -1 don't accept, I still have issues Thanks, Eddie
