Marshall Schor | 1 Mar 05:32 2011

March board report due in a couple of weeks

Maybe we can mention the uima-as release :-)  ?

Tommaso and Joern - can you add something about the work you're doing on
SolrCas, AlchemyAPI, etc. ?

Other possible Items:

Joern got CI going on Hudson

We worked with Sally K to do an Apache Press Release around UIMA use in
"Watson", playing against Jeopardy

Users are building on top of UIMA - example - release of DKPro Core 1.1.0 set of
annotators and tooling.

Please add more significant items ( I think I've missed some because it's about
time to go to sleep...)

-Marshall

Jörn Kottmann (JIRA | 1 Mar 10:19 2011
Picon

[jira] Commented: (UIMA-2047) Solrcas should not resolve the solrmapping file only via the classpath


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

Jörn Kottmann commented on UIMA-2047:
-------------------------------------

Also get this warning with your patch:

3/1/11 10:16:09 AM - 20: org.apache.uima.impl.ChildUimaContext_impl.getResourceAsStream:
WARNING: The unmanaged resource /xxx/apache-uima-as/xxx/desc/solrmapping.xml was accessed.This
feature is deprecated, and support may be removed in future versions.

> Solrcas should not resolve the solrmapping file only via the classpath
> ----------------------------------------------------------------------
>
>                 Key: UIMA-2047
>                 URL: https://issues.apache.org/jira/browse/UIMA-2047
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Sandbox-Solrcas
>            Reporter: Jörn Kottmann
>         Attachments: relativeurl.patch
>
>
> The solrmapping file is currently only resolved via the classpath. It should be possible to place a
solrmapping file next to the AE descriptor and load it like referenced descriptors. 
> The Solrcas jar file also contains a default solrmapping file. That should not be included in the jar file,
otherwise it might accidentally be loaded depending on the location of that jar on the classpath.
(Continue reading)

Jörn Kottmann (JIRA | 1 Mar 10:42 2011
Picon

[jira] Commented: (UIMA-2038) UIMA AS process does not terminate reliably


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

Jörn Kottmann commented on UIMA-2038:
-------------------------------------

Now re-tested with 2.3.1 RC5 and the issue remains. After processing a few CASes the process does not stop
when terminated with "q".

Here are the non-daemon jstack threads:

"DestroyJavaVM" prio=10 tid=0x00007f24ec2b4000 nid=0x370d waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"VmThreadGroup563b24df:12e70c47767:-7ff2_SolrcasAE:Reaper" prio=10 tid=0x00007f24ec2b5000
nid=0x395f in Object.wait() [0x00007f24ea9cf000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00007f251e611b00> (a org.apache.uima.aae.spi.transport.vm.VmTransport$1)
	at org.apache.uima.aae.spi.transport.vm.VmTransport$1.run(VmTransport.java:150)
	- locked <0x00007f251e611b00> (a org.apache.uima.aae.spi.transport.vm.VmTransport$1)

I guess the second thread as a UIMA-AS thread which maybe should be daemon or terminated
in some way.

> UIMA AS process does not terminate reliably
> -------------------------------------------
>
(Continue reading)

Jörn Kottmann (JIRA | 1 Mar 10:42 2011
Picon

[jira] Reopened: (UIMA-2038) UIMA AS process does not terminate reliably


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

Jörn Kottmann reopened UIMA-2038:
---------------------------------

> UIMA AS process does not terminate reliably
> -------------------------------------------
>
>                 Key: UIMA-2038
>                 URL: https://issues.apache.org/jira/browse/UIMA-2038
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>    Affects Versions: 2.3.1AS
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.3.1AS
>
>
> UIMA AS two stop options dont seem to work reliably. Neither 's' nor 'q' on the command line force a clean
shutdown of the process. Actually, there is also a related problem. Namely, when the shutdown succeeds it
appears that the Shared Connection that all Spring listeners use is not closed which leads to an ugly
exception on the broker console. This happens every time the service is terminated. Review listeners
shutdown code and make sure that when the last listener terminates the connection is stopped before the
process exits. Also, make sure that uima threads from custom pools are daemon threads to allow the jvm to
collect them on shutdown. NOTE: AMQ version 4.x internal threads are not daemon threads and there is
special code in the listener to wait for them to stop before exiting. Newer AMQ version use daemon threads
so shutting down AMQ is much more reliable.    
(Continue reading)

Jaroslaw Cwiklik | 1 Mar 17:05 2011
Picon

Re: [jira] Commented: (UIMA-2038) UIMA AS process does not terminate reliably

Jorn, I just committed a few changes. These should fix the hang yu've
reported. If it works close the JIRA
Thanks, JC

2011/3/1 Jörn Kottmann (JIRA) <dev@...>

>
>    [
> https://issues.apache.org/jira/browse/UIMA-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000800#comment-13000800]
>
> Jörn Kottmann commented on UIMA-2038:
> -------------------------------------
>
> Now re-tested with 2.3.1 RC5 and the issue remains. After processing a few
> CASes the process does not stop when terminated with "q".
>
> Here are the non-daemon jstack threads:
>
>
> "DestroyJavaVM" prio=10 tid=0x00007f24ec2b4000 nid=0x370d waiting on
> condition [0x0000000000000000]
>   java.lang.Thread.State: RUNNABLE
>
> "VmThreadGroup563b24df:12e70c47767:-7ff2_SolrcasAE:Reaper" prio=10
> tid=0x00007f24ec2b5000 nid=0x395f in Object.wait() [0x00007f24ea9cf000]
>   java.lang.Thread.State: TIMED_WAITING (on object monitor)
>        at java.lang.Object.wait(Native Method)
>        - waiting on <0x00007f251e611b00> (a
> org.apache.uima.aae.spi.transport.vm.VmTransport$1)
>        at
(Continue reading)

Jörn Kottmann (JIRA | 1 Mar 17:24 2011
Picon

[jira] Closed: (UIMA-2038) UIMA AS process does not terminate reliably


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

Jörn Kottmann closed UIMA-2038.
-------------------------------

    Resolution: Fixed

Tested as request by Jerry and the issue is now fixed on my test system.

> UIMA AS process does not terminate reliably
> -------------------------------------------
>
>                 Key: UIMA-2038
>                 URL: https://issues.apache.org/jira/browse/UIMA-2038
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>    Affects Versions: 2.3.1AS
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.3.1AS
>
>
> UIMA AS two stop options dont seem to work reliably. Neither 's' nor 'q' on the command line force a clean
shutdown of the process. Actually, there is also a related problem. Namely, when the shutdown succeeds it
appears that the Shared Connection that all Spring listeners use is not closed which leads to an ugly
exception on the broker console. This happens every time the service is terminated. Review listeners
shutdown code and make sure that when the last listener terminates the connection is stopped before the
(Continue reading)

Jörn Kottmann | 1 Mar 17:25 2011
Picon

Re: [jira] Commented: (UIMA-2038) UIMA AS process does not terminate reliably

On 3/1/11 5:05 PM, Jaroslaw Cwiklik wrote:
> Jorn, I just committed a few changes. These should fix the hang yu've
> reported. If it works close the JIRA
> Thanks, JC

Works now, I already closed the issue. Do you make a new RC?
If so please drop me a note before, would still like to modify the PID
log message on start up.

Jörn

Jaroslaw Cwiklik | 1 Mar 17:29 2011
Picon

Re: [jira] Commented: (UIMA-2038) UIMA AS process does not terminate reliably

Well, I would like to wait a little while longer to give others a chance to
comment on RC5. Go ahead with the PID modification. As I recall this is
about formatting only. Seems like a tough one :)

JC

On Tue, Mar 1, 2011 at 11:25 AM, Jörn Kottmann <kottmann@...> wrote:

> On 3/1/11 5:05 PM, Jaroslaw Cwiklik wrote:
>
>> Jorn, I just committed a few changes. These should fix the hang yu've
>> reported. If it works close the JIRA
>> Thanks, JC
>>
>
> Works now, I already closed the issue. Do you make a new RC?
> If so please drop me a note before, would still like to modify the PID
> log message on start up.
>
> Jörn
>
Jörn Kottmann (JIRA | 1 Mar 17:32 2011
Picon

[jira] Created: (UIMA-2079) UIMA-AS Service logs a pid on startup, it should be separated with a space

UIMA-AS Service logs a pid on startup, it should be separated with a space
--------------------------------------------------------------------------

                 Key: UIMA-2079
                 URL: https://issues.apache.org/jira/browse/UIMA-2079
             Project: UIMA
          Issue Type: Improvement
          Components: Async Scaleout
            Reporter: Jörn Kottmann
            Assignee: Jörn Kottmann
            Priority: Trivial
             Fix For: 2.3.1AS

The logged PID is frequently needed during testing to stop an UIMA-AS Service which runs in the background.
Since the PID is not separated by a space from the colon it must be selected by moving the mouse in order to copy
it via ctrl+c. 

To improve this add a space before it, then it can be selected by double clicking.

--

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jörn Kottmann | 1 Mar 17:39 2011
Picon

Re: [jira] Commented: (UIMA-2038) UIMA AS process does not terminate reliably

On 3/1/11 5:29 PM, Jaroslaw Cwiklik wrote:
> Well, I would like to wait a little while longer to give others a chance to
> comment on RC5. Go ahead with the PID modification. As I recall this is
> about formatting only. Seems like a tough one :)

I might found one more problem related to this issue with RC5.

I noticed that a simple kill does not work when an AE is constantly 
throwing a RuntimeException
for many of its processed CASes. As far as I understand the kill 
triggers the shutdown hook which
does the quiesce. So even when there are exceptions from the process 
method it should be
possible to quiesce the service.

I will investigate that tomorrow with my now deployed snapshot version.

Jörn


Gmane