Proposed API for CAS Journaling

[Bhavani Iyer]

Please review the intiial proposal for extending the CAS interface to
support journaling posted on the wiki:
http://cwiki.apache.org/confluence/display/UIMA/APIs+for+CAS+Journaling

- Bhavani

[jira] Created: (UIMA-1158) Some shell scripts don't work on Ubuntu Linux

[Burn Lewis (JIRA)]

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


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: [jira] Updated: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Marshall Schor]

No grant is needed, I think - you're not donating the screen shot :-).
-Marshall

Tong Fin wrote:
> When I try to attach the screen-shot, I cannot find the place to "grant" the
> licence.
> I may miss something.
>
> -- Tong
>
>   

[jira] Commented: (UIMA-1129) XMI serialization support for delta CAS

[Bhavani Iyer (JIRA)]

[ 
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] Updated: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Tong Fin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tong Fin updated UIMA-1146:
---

Attachment: DDE_Patch_2of2Modified08-25-2008_JIRA-1146.txt

Marshall,
I replaced the 2nd patch file to add some additional wording for the hover text.
It is safer to apply my 2 patches one more time.

Thanks,
Tong

> 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: Marshall Schor
> 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: [jira] Commented: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Marshall Schor]

Thilo Goetz wrote:
> Marshall Schor wrote:
>   
>> Thilo Goetz wrote:
>> 
>>> I don't know about you guys, but my mail program
>>> doesn't handle wiki syntax.  If we allow wiki
>>> syntax in Jira, can we make it spit out html
>>> mail instead of unformatted wiki syntax?
>>>   
>> Apparantly yes.  See
>> http://www.atlassian.com/software/jira/docs/v3.12/configurerenderers.html
>> and scroll down to Email Notifications.
>> 
>
> Yes, I found that.  You can enable this on an individual
> level, which I did for test purposes.  I still don't get
> html mail, don't know why.
>
> So anyway, wdyt?  I'd say either wiki + html mail, or
> plain text in both.
>   
+1 for wiki + html mail, for me. -Marshall
> --Thilo
>
>
>
>   

[jira] Updated: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Tong Fin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tong Fin updated UIMA-1146:
---

Attachment: (was: DDE_Patch_2of2_JIRA-1146.txt)

> 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: Marshall Schor
> Attachments: DDE_Patch_1of2_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: Cad Editor splitting

[Marshall Schor]

Eddie Epstein wrote:
> This does sound like a good direction. In order to use the CAS viewer it
> should be accepted into the sandbox. Any objection to resubmitting the vote?
>
>   
+1 -Marshall

> Eddie
>
> On Sat, Aug 23, 2008 at 6:32 AM, Jörn Kottmann <[EMAIL PROTECTED]> wrote:
>   
>> Hello,
>>
>> I would likte to move the CAS viewing and editing part out of the
>> Cas Editor into a new plugin to make this part reusable in external
>> applications which want to view and edit a CAS. To make
>> this possible an API for opening CAS based eclipse editors
>> will be defined.
>>
>> The viewing and editing part can then also be used directly
>> from eclipse. To achieve this I suggest that we build a uima
>> development tools plugin which uses the new API
>> for opening a CAS based editor. The UDT plugin can be extended
>> to contain other functionality like launch support for AEs, log viewers,
>> etc.
>>
>> The UDT plugin could use code from the CAS Viewer. Depending
>> on how we continue with the CAS Viewer the viewing part will be put
>> into a new plugin (Level-1 sharing) or merged with the CAS Editor (Level-2
>> sharing).
>>
>> Jörn
>> 
>
>
>   

[jira] Closed: (UIMA-1157) UIMA-AS website download page links are wrong for linux

[Marshall Schor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marshall Schor closed UIMA-1157.


Assignee: Marshall Schor  (was: Burn Lewis)

web site now working :-)

> UIMA-AS website download page links are wrong for linux
> ---
>
> Key: UIMA-1157
> URL: https://issues.apache.org/jira/browse/UIMA-1157
> Project: UIMA
>  Issue Type: Bug
>  Components: Website
>Reporter: Marshall Schor
>Assignee: Marshall Schor
> Fix For: 2.2.2AS
>
>
> The links on the page are missing the .gz  (including the checksums).  Files 
> are OK on the distr, but the links are wrong.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Tong Fin (JIRA)]

[ 
https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625483#action_12625483
 ] 

Tong Fin commented on UIMA-1146:


The following is the UI for the queue listeners of an AS aggregate.
I used the Wiki markup. Does someone have the problem to see the screen-shot ?

!queue-listeners.jpg!

-- Tong



> 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: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, 
> DDE_Patch_2of2_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.

[jira] Resolved: (UIMA-1157) UIMA-AS website download page links are wrong for linux

[Marshall Schor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marshall Schor resolved UIMA-1157.
--

   Resolution: Fixed
Fix Version/s: 2.2.2AS
 Assignee: Burn Lewis  (was: Marshall Schor)

fixed.  Burn, please test after waiting for replication (probably should happen 
by 5 PM EDT).

> UIMA-AS website download page links are wrong for linux
> ---
>
> Key: UIMA-1157
> URL: https://issues.apache.org/jira/browse/UIMA-1157
> Project: UIMA
>  Issue Type: Bug
>  Components: Website
>Reporter: Marshall Schor
>Assignee: Burn Lewis
> Fix For: 2.2.2AS
>
>
> The links on the page are missing the .gz  (including the checksums).  Files 
> are OK on the distr, but the links are wrong.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Tong Fin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tong Fin updated UIMA-1146:
---

Attachment: queue-listeners.jpg

UI for queue listeners of an AS aggregate

> 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: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, 
> DDE_Patch_2of2_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.

[jira] Created: (UIMA-1157) UIMA-AS website download page links are wrong for linux

[Marshall Schor (JIRA)]

UIMA-AS website download page links are wrong for linux
---

 Key: UIMA-1157
 URL: https://issues.apache.org/jira/browse/UIMA-1157
 Project: UIMA
  Issue Type: Bug
  Components: Website
Reporter: Marshall Schor
Assignee: Marshall Schor


The links on the page are missing the .gz  (including the checksums).  Files 
are OK on the distr, but the links are wrong.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Cad Editor splitting

[Adam Lally]

On Mon, Aug 25, 2008 at 2:39 PM, Eddie Epstein <[EMAIL PROTECTED]> wrote:
> This does sound like a good direction. In order to use the CAS viewer it
> should be accepted into the sandbox. Any objection to resubmitting the vote?
>
> Eddie
>

Ok with me.
  -Adam

Re: [jira] Updated: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Tong Fin]

When I try to attach the screen-shot, I cannot find the place to "grant" the
licence.
I may miss something.

-- Tong

[jira] Updated: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Tong Fin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tong Fin updated UIMA-1146:
---

Attachment: (was: queue-listeners.jpg)

> 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: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, 
> DDE_Patch_2of2_JIRA-1146.txt
>
>
> 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.

[jira] Updated: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Tong Fin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tong Fin updated UIMA-1146:
---

Attachment: queue-listeners.jpg

Screen-shot for supporting queue listeners for AS aggregate

BTW, I am testing the Wiki style markup for image.

> 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: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, 
> DDE_Patch_2of2_JIRA-1146.txt
>
>
> 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: Cad Editor splitting

[Eddie Epstein]

This does sound like a good direction. In order to use the CAS viewer it
should be accepted into the sandbox. Any objection to resubmitting the vote?

Eddie

On Sat, Aug 23, 2008 at 6:32 AM, Jörn Kottmann <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I would likte to move the CAS viewing and editing part out of the
> Cas Editor into a new plugin to make this part reusable in external
> applications which want to view and edit a CAS. To make
> this possible an API for opening CAS based eclipse editors
> will be defined.
>
> The viewing and editing part can then also be used directly
> from eclipse. To achieve this I suggest that we build a uima
> development tools plugin which uses the new API
> for opening a CAS based editor. The UDT plugin can be extended
> to contain other functionality like launch support for AEs, log viewers,
> etc.
>
> The UDT plugin could use code from the CAS Viewer. Depending
> on how we continue with the CAS Viewer the viewing part will be put
> into a new plugin (Level-1 sharing) or merged with the CAS Editor (Level-2
> sharing).
>
> Jörn

[jira] Created: (UIMA-1156) [SimpleServer] Add improvement to support UIMA-AS services

[Tong Fin (JIRA)]

[SimpleServer] Add improvement to support UIMA-AS services
--

 Key: UIMA-1156
 URL: https://issues.apache.org/jira/browse/UIMA-1156
 Project: UIMA
  Issue Type: Improvement
  Components: Sandbox-SimpleServer
Reporter: Tong Fin
Assignee: Tong Fin
Priority: Minor


Currently, the Simple Server supports calling to PEAR-based and 
descriptor-based analysis engines.
This improvement will add the support to call UIMA-AS services.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Cad Editor splitting

[Tong Fin]

 Jörn,
The plan looks good to me. I am happy to work with you for this integration.

Should we start at the high-level a little bit by discussing about the flow
? For example, assuming that the input is an xmiCAS or CAS, what is the flow
of the tool up to the point that users see something in Eclipse.

-- Tong

Re: Cas Viewer discussion

[Tong Fin]

Hi Adam,
Please see my in-line comments.

The point of the discussions was not primarily about UI but about
> integration with the CAS Editor (UI just got dragged into it since
> there are UI implications for how the integration is done).

Yes, you are right. We are still talking at the "abstract" level and we have
a small progress that makes me nervous since the time passes so quick
(maybe, I need to be more patient).

 I'd hoped
> that there could be some agreement between you and Joern about how
> integration might happen, but unfortunately the two of you appear to
> have very different views about at what level the sharing might take
> place, and there has been no progress resolving this.

At the "abstract" discussion, I think expressing opinions and concerns from
many peoples (as you, Joern, and I did) are very valuable and important. At
this moment, I think we do agree on the goals which include the one as you
mentioned in you post:

"I don't like having such a confusing array of overlapping tools in UIMA
as a whole."

When we work on the "details", the differences will be gone I think.



> I have mixed feelings about that -
> one one hand, I do like the CAS Viewer as a tool, on the other hand, I
> don't like having such a confusing array of overlapping tools in UIMA
> as a whole.

Thank you to know that the CAS Viewer has an additional happy user :)


> Maybe, it would help alleviate these concerns if your plan included
> more details on how you plan to acheive the integration.
>
> The first step that I try to do with this discussion is to get the CAS
Viewer accepted into the UIMA svn, to express my plan what to do next (like
supporting CAS Journaling), and to hear other people's opinions.
Regarding the integration with other tools (currently with the CAS Editor),
as I mentioned early, we do agree on the goals. For the details, we need to
work together to come out with the plan and propose to the community. I am
sure that all the issues can be resolved at the end.

Now, Joern starts another thread "CAS editor spitting" that is a good
starting point toward  the "details plan" for the integration. I will put my
opinions/comments there and I hope that Joern and I can come out with a
reasonable plan detailed enough to make you optimistic about tooling
integration.

-- Tong

Re: [MAVEN] Plugin id of UIMA runtime "fragment" in UIMA-AS distribution

[Tong Fin]

Hi Marshall,
Thank for the explanation.
I do overlook UIMA-1123.

-- Tong

Re: [jira] Commented: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Thilo Goetz]

Marshall Schor wrote:
> 
> Thilo Goetz wrote:
>> I don't know about you guys, but my mail program
>> doesn't handle wiki syntax.  If we allow wiki
>> syntax in Jira, can we make it spit out html
>> mail instead of unformatted wiki syntax?
> Apparantly yes.  See
> http://www.atlassian.com/software/jira/docs/v3.12/configurerenderers.html
> and scroll down to Email Notifications.

Yes, I found that.  You can enable this on an individual
level, which I did for test purposes.  I still don't get
html mail, don't know why.

So anyway, wdyt?  I'd say either wiki + html mail, or
plain text in both.

--Thilo

Re: [jira] Commented: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates

[Marshall Schor]

Thilo Goetz wrote:
> I don't know about you guys, but my mail program
> doesn't handle wiki syntax.  If we allow wiki
> syntax in Jira, can we make it spit out html
> mail instead of unformatted wiki syntax?
Apparantly yes.  See
http://www.atlassian.com/software/jira/docs/v3.12/configurerenderers.html
and scroll down to Email Notifications.

That page says:


Email Notifications

JIRA allows for extensive configuration in relation to email
notifications
.
JIRA can be send out two types of emails, HTML and text (see 'Email
Formatting
').


HTML Emails

When using the Atlassian Wiki Renderer, the rendered content (i.e.
exactly what you see on the 'View Issue' page) will be sent out in the
emails. This will create emails which are as rich as the content makes
it. If using the Atlassian Wiki Renderer this is the preferred type of
email since it is a real representation of the wiki markup.


Text Emails

When using the Atlassian Wiki Renderer, the actual wiki markup
(unrendered) will be displayed in text emails for fields that use the
Atlassian Wiki Renderer. This is obviously less readable than the
rendered version of the markup, but because the markup's syntax is quite
simple the text does remain easy to read.


>   Any
> drawbacks to that?
>   
Not sure - I've seen in other posts that spam filters sometimes kick in?

-Marshall
> --Thilo
>
> Eddie Epstein (JIRA) wrote:
>   
>> [ 
>> https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624973#action_12624973
>>  ] 
>>
>> Eddie Epstein commented on UIMA-1146:
>> -
>>
>> Resubmitting last comment with correct formatting marks, just in case they 
>> work here :)
>>
>> bq. I'm a little concerned that we are adding a lot of parameters that may 
>> be tricky to tune. Presumably most applications will take the default but 
>> for those that may benefit from scaleout it may be hard to determine which 
>> queue needs the extra threads.
>>
>> There are a lot of parameters which can be tuned with UIMA AS, but as you 
>> note, most applications will not need to. The real issue is to know when and 
>> how to tune them. Turns out that "when" is pretty easy to answer: is the CPU 
>> fully utilized? If not, the monitor function (see UIMA-1104) has been very 
>> successful in identifying bottlenecks in order to answer "how".
>>
>> {quote} 
>> For an aggregate with N remote delegates and at least 1 co-located we'll 
>> have N+2 parameters to consider. Since these 3 types of queue consumers are 
>> all doing similar work, dispatching the CASes within the aggregate, wouldn't 
>> it be nice if we could have only 1 scaleout parameter for each aggregate.
>>  
>>  This would let users focus more on the aggregate as a dispatcher of work, 
>> and less on the subtleties of our implementation.
>> {quote}
>>
>> When used with Uima AS primitives, "scaleout" means to replicate instances 
>> of analysis components. Overloading "scaleout" to refer to replicating some 
>> threads in an aggregate will result in unnecessary confusion.
>>
>> {quote}
>> We could support this by using a Java queue for all replies (not just 
>> co-located ones as proposed elsewhere) and scale out the dispatch threads 
>> that consume this queue. The input queue and each remote queue would still 
>> have dedicated threads, but they would merely put the message on the Java 
>> queue along with the appropriate CAS, after blocking on the CasPool if 
>> necessary.
>>
>> One drawback is the extra thread switch but this may be small compared with 
>> the transport time for a remote. Another is that the extra consumers of 
>> remote queues are expected to replace the need for prefetch, but since this 
>> proposal separates the fetching from the dispatching the lightweight fetch 
>> thread may achieve the same effect as pretetch.
>> {quote}
>>
>> Individual remote reply queues still need to be scaled (see UIMA-1130), so 
>> we need exactly what Marshall has proposed above. UIMA-1140 advocates using 
>> a Java queue for colocated delegates. When that gets done we can consider if 
>> piping all replies through the java queue makes sense. 
>>
>> 
>>> 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
>>>
>>> JIRA-1130 has improved UIMA-AS to allow users to set the number of 
>>> concurrent listeners o

Re: [MAVEN] Plugin id of UIMA runtime "fragment" in UIMA-AS distribution

[Marshall Schor]

Tong Fin wrote:
> Something is wrong with my keybord ... Resent the mail.
>
> When I rebuilt the UIMA runtime "fragment" used by the Deployment Descriptor
> Editor, I got the target jar having the following name:
>  org.apache.uima.runtime.fragments.deployeditor_2.2.2.incubating.jar
> which is consistent with the bundle-name in manifest.mf:
>  Bundle-SymbolicName: org.apache.uima.runtime.fragments.deployeditor
> and with what we have in pom.
>
> But, the jar file for this "fragment" in the UIMA-AS distribution is:
> org.apache.uima.runtime-deployeditor.2.2.2.incubating.jar
>
> Is there any reason to re-name the jar file to be different from the
> fragment id ?
> (Eclipse suggests to have "same" name).
>
> Either name is fine with me, but I prefer them to be the same.
>   
Does the comment in http://issues.apache.org/jira/browse/UIMA-1123
explain this?

I found when building the Eclipse update site that the jar name has to
match the "id".  So, I changed the build and POM for this as part of
creating the update site.

Because we had already released 2.2.2-incubating, that jar name (the one
in the binary distribution in the Eclipse Plugins directory) wasn't changed.

For subsequent releases, as it stands now, because the POM was changed,
the jar name in the binary distribution in the Eclipse Plugins directory
will change to match what it is in the update site.

-Marshall
> -- Tong
>
>   

[VOTE] Release uimacpp-2.2.2-03 as uimacpp-2.2.2-incubating

[Eddie Epstein]

All of the issues raised during discussion of the last release
candidate (http://markmail.org/message/z5d4o3hempxeo4sw)
have been addressed.

The release artifacts and RAT results are available on
p.a.o/~eae/uimacpp-release-candidates/2.2.2/03/

Please cast your vote:

[ ] +1 release candidate uimacpp-2.2.2-incubating RC03 is ready and
can be released
[ ] 0 don't care
[ ] -1 don't release yet, I found some more issues

Thanks, Eddie

Re: Cad Editor splitting

[Adam Lally]

On Sat, Aug 23, 2008 at 6:32 AM, Jörn Kottmann <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I would likte to move the CAS viewing and editing part out of the
> Cas Editor into a new plugin to make this part reusable in external
> applications which want to view and edit a CAS. To make
> this possible an API for opening CAS based eclipse editors
> will be defined.
>
> The viewing and editing part can then also be used directly
> from eclipse. To achieve this I suggest that we build a uima
> development tools plugin which uses the new API
> for opening a CAS based editor. The UDT plugin can be extended
> to contain other functionality like launch support for AEs, log viewers,
> etc.
>
> The UDT plugin could use code from the CAS Viewer. Depending
> on how we continue with the CAS Viewer the viewing part will be put
> into a new plugin (Level-1 sharing) or merged with the CAS Editor (Level-2
> sharing).
>
> Jörn

Sounds right to me.
  -Adam

[jira] Commented: (UIMA-1129) XMI serialization support for delta CAS

[Thilo Goetz (JIRA)]

[ 
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.