[jira] [Commented] (UIMA-5611) UIMA-DUCC: Agent fails to kill a child process sometimes

2017-10-10 Thread Burn Lewis (JIRA) 

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

Burn Lewis commented on UIMA-5611:
--

These became defunct processes so kill -9 won't help ... perhaps agent should 
treat them as gone.

> UIMA-DUCC: Agent fails to kill a child process sometimes
> 
>
> Key: UIMA-5611
> URL: https://issues.apache.org/jira/browse/UIMA-5611
> Project: UIMA
>  Issue Type: Bug
>  Components: DUCC
>Reporter: Jerry Cwiklik
>Assignee: Jerry Cwiklik
> Fix For: 2.2.2-Ducc
>
>
> Improve detection of child processes which fail to stop after kill -9 was 
> sent. If kill -9 is sent by an agent while a child process is experiencing an 
> OOM, the signal is not acted upon and the process remains running.
> An agent should retry kill -9 on regular basis (configured in 
> ducc.properties) if a process is still standing after kill -9.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Jenkins build is back to normal : UIMA-Ruta-v3 #7

2017-10-10 Thread Apache Jenkins Server 
See

[jira] [Created] (UIMA-5612) update the uima-wide shared superPOM

2017-10-10 Thread Marshall Schor (JIRA) 
Marshall Schor created UIMA-5612:


 Summary: update the uima-wide shared superPOM
 Key: UIMA-5612
 URL: https://issues.apache.org/jira/browse/UIMA-5612
 Project: UIMA
  Issue Type: Improvement
  Components: Build, Packaging and Test
Reporter: Marshall Schor
Priority: Minor


Things to update:
1) version of it's parent
2) version of many plugins.  e.g. the maven release plugin
3) The Eclipse update site building - to support code-signing
Please add your candidates:-)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: signing Eclipse Plugins - a proposed approach

2017-10-10 Thread Marshall Schor 
second attempt - signed the feature jars, too. 

Got the same "unsigned content" warning, but this time I continued, and to my
surprise, it asked me if I trusted these certificates (and it showed the
Symantec "TEST" signing certificate) - I said yes, and it completed.  So I guess
that counts as working. 

To be determined: it might have worked without signing the feature jars - but
probably it's better to have all the (jar) artifacts signed anyways.

To be determined later, see if the production signing makes the "unsigned
content" warning go away.

-Marshall


On 10/10/2017 11:43 AM, Marshall Schor wrote:
> one improvement - will document shortly on website:
>
>   skip step 1 - no need to "prepare-to-sign".
>
> Instead, (after a small fix to the normal build) take all the Jars in the
> target/eus-work/plugins that are *.jar files, and sign these.
>
> This is of course, better, in that it doesn't "rebuild them".
>
> -Marshall
>
>
> On 10/10/2017 11:34 AM, Marshall Schor wrote:
>> I've documented a proposed approach on the website:
>> https://uima.apache.org/dev-eclipse-plugin-signing
>>
>> This can also be reached from the
>>   home page ->
>>     (left nav bar) Eclipse Update Sites ->
>>   Information for developers ->
>>     information about plugin signing
>>
>> The basic idea is a 2 phase approach - the first phase is normal, like now, 
>> no
>> signing, producing the release candidate to vote on.  Once the Vote passes, 
>> then
>> a simple/mechanical repackaging of the update site is done, including 
>> signing,
>> with just a sanity check at the end that the result installs:
>>
>>   1. run the ant script "prepare-to-sign"
>>   2. manually sign on to the signing portal, upload the jars in
>> target/eus-work/plugins, sign them, and download the signed jars to
>> target/eus-work-signed/plugins
>>   3. run the ant script "finish-after-signing"
>>
>> This avoids charging Apache for signing for release candidates that 
>> subsequently
>> fail.  Because the actions following the vote are only mechanical "binary"
>> packaging, I think we don't need another vote. 
>>
>> I'm working on making the ant scripts for this, using the uimaj-v3 as the 
>> guinea
>> pig.
>>
>> WDYT?
>>
>> -Marshall
>>
>>
>

Re: testing uv3 with ...?

2017-10-10 Thread Marshall Schor 
re: the second failure: (no such element exception) I think that's now fixed in
trunk. 

-Marshall


On 10/10/2017 4:03 PM, Richard Eckart de Castilho wrote:
> On 09.10.2017, at 16:35, Marshall Schor  wrote:
>> I think this will need a test case - can you provide one?
> I can see the extended error message and will try to produce a reduced unit 
> test.
>
> org.apache.uima.cas.CASRuntimeException: Deserializing Compressed Form 6, a 
> type code: 71 has no corresponding type. currentFsId: 1 nbrFSs: 0 nextFsAddr: 
> 1 
>   at 
> org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1812)
>   at 
> org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:594)
>   at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:382)
>   at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:344)
> ...
>
> With the latest changes, some additional tests are failing with a new stack 
> trace:
>
> Caused by: java.util.NoSuchElementException
>   at 
> org.apache.uima.internal.util.CopyOnWriteOrderedFsSet_array$1.next(CopyOnWriteOrderedFsSet_array.java:132)
>   at 
> org.apache.uima.internal.util.CopyOnWriteOrderedFsSet_array$1.next(CopyOnWriteOrderedFsSet_array.java:120)
>   at 
> org.apache.uima.cas.impl.FSIndexRepositoryImpl$1$1.next(FSIndexRepositoryImpl.java:1578)
>   at 
> org.apache.uima.cas.impl.FSIndexRepositoryImpl$1$1.next(FSIndexRepositoryImpl.java:1563)
>   at org.apache.uima.cas.impl.AllFSs.getFSsForView(AllFSs.java:115)
>   at 
> org.apache.uima.cas.impl.AllFSs.lambda$getAllFSsAllViews_sofas$1(AllFSs.java:89)
>   at org.apache.uima.cas.impl.CASImpl.forAllViews(CASImpl.java:4440)
>   at 
> org.apache.uima.cas.impl.AllFSs.getAllFSsAllViews_sofas(AllFSs.java:89)
>   at 
> org.apache.uima.cas.impl.AllFSs.getAllFSsAllViews_sofas_reachable(AllFSs.java:95)
>   at 
> org.apache.uima.cas.impl.BinaryCasSerDes6.processIndexedFeatureStructures(BinaryCasSerDes6.java:2820)
>   at 
> org.apache.uima.cas.impl.BinaryCasSerDes6.serialize(BinaryCasSerDes6.java:747)
>   at 
> org.apache.uima.cas.impl.Serialization.serializeWithCompression(Serialization.java:247)
>   at org.apache.uima.util.CasIOUtils.save(CasIOUtils.java:483)
>   ... 34 more
>
> I'll also try to isolate this case.
>
> Best,
>
> -- Richard
>
>
>

Re: testing uv3 with ...?

2017-10-10 Thread Richard Eckart de Castilho 
On 10.10.2017, at 22:03, Richard Eckart de Castilho  wrote:
> 
> On 09.10.2017, at 16:35, Marshall Schor  wrote:
>> 
>> I think this will need a test case - can you provide one?
> 
> I can see the extended error message and will try to produce a reduced unit 
> test.
> 
> org.apache.uima.cas.CASRuntimeException: Deserializing Compressed Form 6, a 
> type code: 71 has no corresponding type. currentFsId: 1 nbrFSs: 0 nextFsAddr: 
> 1 
>   at 
> org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1812)
>   at 
> org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:594)
>   at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:382)
>   at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:344)
>...

This seems to happen only when CasIOUtils.load(casInputStream, aCAS, 
typeSystem) is used.
I tried to set up a minimal test which serializes a CAS into one byte-array for 
the contents
and a second one for the type system, then deserializes this into a new CAS 
using the
method above. However, this doesn't seem to trigger the problem. So it might be 
related
to the fact that in the failing DKPro Core test, there are also two collection 
reader components
and an analysis engine (actually a writing component) involved.

I'll try to expand the test until it fails. If you have any additional 
pointers, please
let me know.

Cheers,

-- Richard

Re: signing Eclipse Plugins - a proposed approach

2017-10-10 Thread Marshall Schor 
First attempt: did a test signing of the 8 jars in the plugin dir.  Didn't
succeed - Looks like maybe you need to sign the Jars used for features too.  I'm
trying that next.  -Marshall


On 10/10/2017 11:43 AM, Marshall Schor wrote:
> one improvement - will document shortly on website:
>
>   skip step 1 - no need to "prepare-to-sign".
>
> Instead, (after a small fix to the normal build) take all the Jars in the
> target/eus-work/plugins that are *.jar files, and sign these.
>
> This is of course, better, in that it doesn't "rebuild them".
>
> -Marshall
>
>
> On 10/10/2017 11:34 AM, Marshall Schor wrote:
>> I've documented a proposed approach on the website:
>> https://uima.apache.org/dev-eclipse-plugin-signing
>>
>> This can also be reached from the
>>   home page ->
>>     (left nav bar) Eclipse Update Sites ->
>>   Information for developers ->
>>     information about plugin signing
>>
>> The basic idea is a 2 phase approach - the first phase is normal, like now, 
>> no
>> signing, producing the release candidate to vote on.  Once the Vote passes, 
>> then
>> a simple/mechanical repackaging of the update site is done, including 
>> signing,
>> with just a sanity check at the end that the result installs:
>>
>>   1. run the ant script "prepare-to-sign"
>>   2. manually sign on to the signing portal, upload the jars in
>> target/eus-work/plugins, sign them, and download the signed jars to
>> target/eus-work-signed/plugins
>>   3. run the ant script "finish-after-signing"
>>
>> This avoids charging Apache for signing for release candidates that 
>> subsequently
>> fail.  Because the actions following the vote are only mechanical "binary"
>> packaging, I think we don't need another vote. 
>>
>> I'm working on making the ant scripts for this, using the uimaj-v3 as the 
>> guinea
>> pig.
>>
>> WDYT?
>>
>> -Marshall
>>
>>
>

Re: testing uv3 with ...?

2017-10-10 Thread Richard Eckart de Castilho 
On 09.10.2017, at 16:35, Marshall Schor  wrote:
> 
> I think this will need a test case - can you provide one?

I can see the extended error message and will try to produce a reduced unit 
test.

org.apache.uima.cas.CASRuntimeException: Deserializing Compressed Form 6, a 
type code: 71 has no corresponding type. currentFsId: 1 nbrFSs: 0 nextFsAddr: 1 
at 
org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1812)
at 
org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:594)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:382)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:344)
...

With the latest changes, some additional tests are failing with a new stack 
trace:

Caused by: java.util.NoSuchElementException
at 
org.apache.uima.internal.util.CopyOnWriteOrderedFsSet_array$1.next(CopyOnWriteOrderedFsSet_array.java:132)
at 
org.apache.uima.internal.util.CopyOnWriteOrderedFsSet_array$1.next(CopyOnWriteOrderedFsSet_array.java:120)
at 
org.apache.uima.cas.impl.FSIndexRepositoryImpl$1$1.next(FSIndexRepositoryImpl.java:1578)
at 
org.apache.uima.cas.impl.FSIndexRepositoryImpl$1$1.next(FSIndexRepositoryImpl.java:1563)
at org.apache.uima.cas.impl.AllFSs.getFSsForView(AllFSs.java:115)
at 
org.apache.uima.cas.impl.AllFSs.lambda$getAllFSsAllViews_sofas$1(AllFSs.java:89)
at org.apache.uima.cas.impl.CASImpl.forAllViews(CASImpl.java:4440)
at 
org.apache.uima.cas.impl.AllFSs.getAllFSsAllViews_sofas(AllFSs.java:89)
at 
org.apache.uima.cas.impl.AllFSs.getAllFSsAllViews_sofas_reachable(AllFSs.java:95)
at 
org.apache.uima.cas.impl.BinaryCasSerDes6.processIndexedFeatureStructures(BinaryCasSerDes6.java:2820)
at 
org.apache.uima.cas.impl.BinaryCasSerDes6.serialize(BinaryCasSerDes6.java:747)
at 
org.apache.uima.cas.impl.Serialization.serializeWithCompression(Serialization.java:247)
at org.apache.uima.util.CasIOUtils.save(CasIOUtils.java:483)
... 34 more

I'll also try to isolate this case.

Best,

-- Richard

[jira] [Commented] (UIMA-5610) DUCC Web Server (WS) document requirement for JDK vs. JRE for JSP compilation

2017-10-10 Thread Lou DeGenaro (JIRA) 

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

Lou DeGenaro commented on UIMA-5610:


Revised SW prereq text.

Java JDK 7 or 8. DUCC has been tested and run using IBM and Oracle JDK 1.7 \& 
1.8.  A JDK is required by DUCC's web server for JSP compilations, for which a 
JRE is insufficient. 

> DUCC Web Server (WS) document requirement for JDK vs. JRE for JSP compilation
> -
>
> Key: UIMA-5610
> URL: https://issues.apache.org/jira/browse/UIMA-5610
> Project: UIMA
>  Issue Type: Documentation
>  Components: DUCC
>Reporter: Lou DeGenaro
>Assignee: Lou DeGenaro
> Fix For: 2.2.2-Ducc
>
>
> Update DUCC documentation to specify that a JDK is required so that WS can 
> compile JSPs.  JRE won't work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (UIMA-5610) DUCC Web Server (WS) document requirement for JDK vs. JRE for JSP compilation

2017-10-10 Thread Lou DeGenaro (JIRA) 

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

Lou DeGenaro closed UIMA-5610.
--
Resolution: Fixed

> DUCC Web Server (WS) document requirement for JDK vs. JRE for JSP compilation
> -
>
> Key: UIMA-5610
> URL: https://issues.apache.org/jira/browse/UIMA-5610
> Project: UIMA
>  Issue Type: Documentation
>  Components: DUCC
>Reporter: Lou DeGenaro
>Assignee: Lou DeGenaro
> Fix For: 2.2.2-Ducc
>
>
> Update DUCC documentation to specify that a JDK is required so that WS can 
> compile JSPs.  JRE won't work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Work started] (UIMA-5610) DUCC Web Server (WS) document requirement for JDK vs. JRE for JSP compilation

2017-10-10 Thread Lou DeGenaro (JIRA) 

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

Work on UIMA-5610 started by Lou DeGenaro.
--
> DUCC Web Server (WS) document requirement for JDK vs. JRE for JSP compilation
> -
>
> Key: UIMA-5610
> URL: https://issues.apache.org/jira/browse/UIMA-5610
> Project: UIMA
>  Issue Type: Documentation
>  Components: DUCC
>Reporter: Lou DeGenaro
>Assignee: Lou DeGenaro
> Fix For: 2.2.2-Ducc
>
>
> Update DUCC documentation to specify that a JDK is required so that WS can 
> compile JSPs.  JRE won't work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (UIMA-5611) UIMA-DUCC: Agent fails to kill a child process sometimes

2017-10-10 Thread Jerry Cwiklik (JIRA) 
Jerry Cwiklik created UIMA-5611:
---

 Summary: UIMA-DUCC: Agent fails to kill a child process sometimes
 Key: UIMA-5611
 URL: https://issues.apache.org/jira/browse/UIMA-5611
 Project: UIMA
  Issue Type: Bug
  Components: DUCC
Reporter: Jerry Cwiklik
Assignee: Jerry Cwiklik
 Fix For: 2.2.2-Ducc


Improve detection of child processes which fail to stop after kill -9 was sent. 
If kill -9 is sent by an agent while a child process is experiencing an OOM, 
the signal is not acted upon and the process remains running.
An agent should retry kill -9 on regular basis (configured in ducc.properties) 
if a process is still standing after kill -9.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: signing Eclipse Plugins - a proposed approach

2017-10-10 Thread Marshall Schor 
one improvement - will document shortly on website:

  skip step 1 - no need to "prepare-to-sign".

Instead, (after a small fix to the normal build) take all the Jars in the
target/eus-work/plugins that are *.jar files, and sign these.

This is of course, better, in that it doesn't "rebuild them".

-Marshall


On 10/10/2017 11:34 AM, Marshall Schor wrote:
> I've documented a proposed approach on the website:
> https://uima.apache.org/dev-eclipse-plugin-signing
>
> This can also be reached from the
>   home page ->
>     (left nav bar) Eclipse Update Sites ->
>   Information for developers ->
>     information about plugin signing
>
> The basic idea is a 2 phase approach - the first phase is normal, like now, no
> signing, producing the release candidate to vote on.  Once the Vote passes, 
> then
> a simple/mechanical repackaging of the update site is done, including signing,
> with just a sanity check at the end that the result installs:
>
>   1. run the ant script "prepare-to-sign"
>   2. manually sign on to the signing portal, upload the jars in
> target/eus-work/plugins, sign them, and download the signed jars to
> target/eus-work-signed/plugins
>   3. run the ant script "finish-after-signing"
>
> This avoids charging Apache for signing for release candidates that 
> subsequently
> fail.  Because the actions following the vote are only mechanical "binary"
> packaging, I think we don't need another vote. 
>
> I'm working on making the ant scripts for this, using the uimaj-v3 as the 
> guinea
> pig.
>
> WDYT?
>
> -Marshall
>
>

signing Eclipse Plugins - a proposed approach

2017-10-10 Thread Marshall Schor 
I've documented a proposed approach on the website:
https://uima.apache.org/dev-eclipse-plugin-signing

This can also be reached from the
  home page ->
    (left nav bar) Eclipse Update Sites ->
  Information for developers ->
    information about plugin signing

The basic idea is a 2 phase approach - the first phase is normal, like now, no
signing, producing the release candidate to vote on.  Once the Vote passes, then
a simple/mechanical repackaging of the update site is done, including signing,
with just a sanity check at the end that the result installs:

  1. run the ant script "prepare-to-sign"
  2. manually sign on to the signing portal, upload the jars in
target/eus-work/plugins, sign them, and download the signed jars to
target/eus-work-signed/plugins
  3. run the ant script "finish-after-signing"

This avoids charging Apache for signing for release candidates that subsequently
fail.  Because the actions following the vote are only mechanical "binary"
packaging, I think we don't need another vote. 

I'm working on making the ant scripts for this, using the uimaj-v3 as the guinea
pig.

WDYT?

-Marshall

[jira] [Created] (UIMA-5610) DUCC Web Server (WS) document requirement for JDK vs. JRE for JSP compilation

2017-10-10 Thread Lou DeGenaro (JIRA) 
Lou DeGenaro created UIMA-5610:
--

 Summary: DUCC Web Server (WS) document requirement for JDK vs. JRE 
for JSP compilation
 Key: UIMA-5610
 URL: https://issues.apache.org/jira/browse/UIMA-5610
 Project: UIMA
  Issue Type: Documentation
  Components: DUCC
Reporter: Lou DeGenaro
Assignee: Lou DeGenaro
 Fix For: 2.2.2-Ducc


Update DUCC documentation to specify that a JDK is required so that WS can 
compile JSPs.  JRE won't work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)