Isabel Drost | 2 Feb 07:51
Picon
Favicon
Gravatar

Hadoop Get Together @ Berlin


Hello,

I would like to announce the fourth German Hadoop Get Together in Berlin. 
Although "Hadoop" is in the title, the topics are of course not strictly 
limited: If you have interesting stories to tell on scaling Lucene or UIMA to 
high traffic or large amounts of documents, feel free to contribute as well. 

This is going to be the fourth German Hadoop get together in Berlin. As always 
there will be slots of 20min each for talks on your Hadoop topic. After each 
talk there will be a lot time to discuss.

You can order drinks directly at the bar in the newthinking store. If you 
like, you can order pizza. There are quite a few good restaurants nearby, so 
we can go there after the official part.

Talks scheduled so far:

Lars George is going to give a presentation of this experiences setting up and 
maintaining a decently large HBase deployment.

We would like to invite you, the visitor to also tell your Hadoop story, if 
you like, you can bring slides - there will be a beamer.

A big Thanks goes to the newthinking store for providing a room in the center 
of Berlin for us. Thanks to newthinking there will be videos of the event 
online after the meeting.

Additional information will be posted on http://www.isabel-drost.de/hadoop and 
on upcoming.org: http://upcoming.yahoo.com/event/1764187
(Continue reading)

Picon
Favicon

[jira] Created: (UIMA-1286) UIMA AS Service Doesnt Start a Timer On Connection To a Temp Reply Queue

UIMA AS Service Doesnt Start a Timer On Connection To a Temp Reply Queue
------------------------------------------------------------------------

                 Key: UIMA-1286
                 URL: https://issues.apache.org/jira/browse/UIMA-1286
             Project: UIMA
          Issue Type: Bug
          Components: Async Scaleout
            Reporter: Jerry Cwiklik

The Uima AS service doesnt time out idle connections to a broker. This may lead to an exception:

ERROR TransportConnector             - Could not accept connection : java.net.SocketException: Too many open files
java.net.SocketException: Too many open files

This problem may occur when a client application repeatedly restarts Uima Client API many times. After
each restart the client sends a CAS and receives a response, then it is stopped. The service accumulates
connections to the client's temp reply queue. When the client terminates the broker kills the temp queue
but the service still keeps the connection open causing a leak.

Start a timer after each reply. 

--

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

Picon
Favicon

[jira] Updated: (UIMA-1286) UIMA AS Service Doesnt Start a Timer On Connection To a Temp Reply Queue


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

Jerry Cwiklik updated UIMA-1286:
--------------------------------

    Attachment: uimaj-as-activemq-UIMA-1286-patch.txt

Starts a timer after each reply to enable idle connection cleanup. A default connection timeout is 30
minutes. To override this add -DSessionTimeoutOverride=XXX, where XXX is time out value in millis

Re-factored sendCasToRemoteEndpoint() methods to remove duplicate code.

> UIMA AS Service Doesnt Start a Timer On Connection To a Temp Reply Queue
> ------------------------------------------------------------------------
>
>                 Key: UIMA-1286
>                 URL: https://issues.apache.org/jira/browse/UIMA-1286
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-1286-patch.txt
>
>
> The Uima AS service doesnt time out idle connections to a broker. This may lead to an exception:
> ERROR TransportConnector             - Could not accept connection : java.net.SocketException: Too many open files
> java.net.SocketException: Too many open files
> This problem may occur when a client application repeatedly restarts Uima Client API many times. After
(Continue reading)

Picon
Favicon

[jira] Updated: (UIMA-1173) BaseUIMAAsynchronousEngine_impl.getCAS() should queue requests


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

Jerry Cwiklik updated UIMA-1173:
--------------------------------

    Attachment: uimaj-as-jms-UIMA-1173-patch.txt

Modified Uima AS client code to queue requests for a CAS. Each thread requesting a CAS will add its request to
a queue. When a CAS becomes available, the oldest thread is selected from the queue and allowed to use the
CAS for processing. 

> BaseUIMAAsynchronousEngine_impl.getCAS() should queue requests
> --------------------------------------------------------------
>
>                 Key: UIMA-1173
>                 URL: https://issues.apache.org/jira/browse/UIMA-1173
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>            Reporter: Eddie Epstein
>         Attachments: uimaj-as-jms-UIMA-1173-patch.txt
>
>
> BaseUIMAAsynchronousEngine_impl.getCAS() blocks until a CAS is available. 
> If multiple threads are blocked, which one gets the next CAS is nondeterministic.
> In order to guarantee quality of service it is important to return CASes in the order
> they were requested.

(Continue reading)

Picon
Favicon

[jira] Closed: (UIMA-1285) Fix Flow Object Not In Flow Cache Error


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

Jerry Cwiklik closed UIMA-1285.
-------------------------------

    Resolution: Fixed

> Fix Flow Object Not In Flow Cache Error
> ---------------------------------------
>
>                 Key: UIMA-1285
>                 URL: https://issues.apache.org/jira/browse/UIMA-1285
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-1285-patch.txt, uimaj-as-core-UIMA-1285-patch.txt
>
>
> CASes returned from an inner aggregate CM are not associated with an input CAS. An error occurs when the
client aggregate attempts to locate a Flow Object using an invalid Cas reference id. When an inner
aggregate returns a CAS back to the client it must set the parent id property to the id of the input CAS.

--

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

(Continue reading)

Picon
Favicon

[jira] Closed: (UIMA-1255) Modify UIMA-AS Aggregate to Handle Cas Not Found Error


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

Jerry Cwiklik closed UIMA-1255.
-------------------------------

    Resolution: Fixed

> Modify UIMA-AS Aggregate to Handle Cas Not Found Error
> ------------------------------------------------------
>
>                 Key: UIMA-1255
>                 URL: https://issues.apache.org/jira/browse/UIMA-1255
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-1255-patch.txt, uimaj-as-core-UIMA-1255-patch.txt
>
>
> Catch Cas Not Found exception in the finalStep(), log it and return. This exception can occur when one
thread is processing a child of an input CAS in parallel with another thread processing a second child of
the same CAS. The first thread may remove the input CAS before the second thread completes.
> When this happens, the second thread eventually will try to fetch the input CAS but by that time the CAS no
longer exists. An exception is thrown and send through the error handler which reports it to a client. This
exception should be handled by the aggregate and not sent to the client.

--

-- 
This message is automatically generated by JIRA.
(Continue reading)

Picon
Favicon

[jira] Closed: (UIMA-1127) Services that timeout should be handled differently on subsequent requests


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

Jerry Cwiklik closed UIMA-1127.
-------------------------------

    Resolution: Fixed

> Services that timeout should be handled differently on subsequent requests
> --------------------------------------------------------------------------
>
>                 Key: UIMA-1127
>                 URL: https://issues.apache.org/jira/browse/UIMA-1127
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>    Affects Versions: 2.2.2
>            Reporter: Eddie Epstein
>            Assignee: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-1127-patch-FixesClientApiPing.txt,
uimaj-as-activemq-UIMA-1127-patch.txt,
uimaj-as-core-UIMA-1127-patch-FixesClientApiPing.txt,
uimaj-as-core-UIMA-1127-patch-PingTimeoutEH.txt, uimaj-as-core-UIMA-1127-patch.txt,
uimaj-as-jms-UIMA-1127-patch-FixesClientApiPing.txt,
uimaj-as-jms-UIMA-1127-patch-PingTimeoutAbort.txt,
uimaj-as-jms-UIMA-1127-patch-PingTimeoutEH.txt, uimaj-as-jms-UIMA-1127-patch.txt
>
>
> When a request times out, the service should be put into a "questionable" state. Requests to a service in
(Continue reading)

Picon
Favicon

[jira] Closed: (UIMA-1279) UIMA AS Client Not Handling Errors When Deploying Synchronous Aggregate


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

Jerry Cwiklik closed UIMA-1279.
-------------------------------

    Resolution: Fixed

> UIMA AS Client Not Handling Errors When Deploying Synchronous Aggregate
> -----------------------------------------------------------------------
>
>                 Key: UIMA-1279
>                 URL: https://issues.apache.org/jira/browse/UIMA-1279
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-1279-patch.txt, uimaj-as-core-UIMA-1279-patch.txt, uimaj-as-jms-UIMA-1279-patch.txt
>
>
> Uima AS Client hangs while handling errors that occur during a deployment of synchronous aggregate. Need
new testcases to test deployment of synchronous aggregate using jms service descriptor.

--

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

(Continue reading)

Picon
Favicon

[jira] Closed: (UIMA-1133) Timeout needs different implementation to eliminate interaction with CAS pool size


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

Jerry Cwiklik closed UIMA-1133.
-------------------------------

    Resolution: Fixed

> Timeout needs different implementation to eliminate interaction with CAS pool size
> ----------------------------------------------------------------------------------
>
>                 Key: UIMA-1133
>                 URL: https://issues.apache.org/jira/browse/UIMA-1133
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>            Reporter: Eddie Epstein
>            Assignee: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-1133-patch2.txt, uimaj-as-core-UIMA-1133-patch2.txt, uimaj-as-jms-UIMA-1133-patch2.txt
>
>
> When a timeout value is specified for process calls, a timer is set for each processCas request. If an
aggregate controller (or client API) sends multiple process requests to the same service, the timeout
must be increased to account for the potential processing delay of the earlier requests. Currently the
timeout value is static, specified in the deployment descriptor; if a user changes the CAS pools size,
they may have to change the timeout to compensate.
> A better design would decouple these things by changing the implementation of timeout. For example, the
timeout value could be dynamic, taking into account the number of outstanding requests sent by the same
client. The new implementation should take into account the need to set appropriate time-to-live values
(Continue reading)

Jörn Kottmann | 3 Feb 14:28
Picon

UIMA-AS deployAsyncService.sh

Hi everyone,

on my macbook the deployAsyncService.sh script fails to start
if the UIMA_HOME contains a whitespace.

Here the error messsage:
Exception in thread "main" java.lang.NoClassDefFoundError: 2/config/ 
Logger/properties

In that case UIMA_HOME="/Users/kottmann/Downloads/apache-uima-as 2"

For now I just changed the path,  should I open a jira issue for it ?

Jörn

Gmane