Picon
Favicon

[jira] Updated: (UIMA-1217) entityProcessComplete returns null CAS on error


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

Jerry Cwiklik updated UIMA-1217:
--------------------------------

    Attachment: uimaj-as-jms-UIMA-1217-patch-Release-2-2-2.txt

> entityProcessComplete returns null CAS on error
> -----------------------------------------------
>
>                 Key: UIMA-1217
>                 URL: https://issues.apache.org/jira/browse/UIMA-1217
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>    Affects Versions: 2.2.2
>            Reporter: Eddie Epstein
>         Attachments: uimaj-as-jms-UIMA-1217-patch-Release-2-2-2.txt, uimaj-as-jms-UIMA-1217-patch.txt
>
>
> Given that the UIMA AS client API caches outgoing CASes while waiting for a service reply, instead of
returning CAS=null on error, the outgoing CAS should be returned.

--

-- 
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] Reopened: (UIMA-1216) UIMA AS Client Code Doesn't Release CAS While Handling Process Exception


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

Jerry Cwiklik reopened UIMA-1216:
---------------------------------

      Assignee: Jerry Cwiklik

Reopened to attach a patch for 2.2.2 release

> UIMA AS Client Code Doesn't Release CAS While Handling Process Exception
> ------------------------------------------------------------------------
>
>                 Key: UIMA-1216
>                 URL: https://issues.apache.org/jira/browse/UIMA-1216
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>         Attachments: uimaj-as-jms-UIMA-1216-patch.txt
>
>
> UIMA AS client framework code caches a CAS before sending (async) request to UIMA AS service. When the
reply is received the CAS is retrieved from the cache, the client (user) code is called via a listener and
the CAS is subsequently released.  For synchronous calls the user code is responsible for each CAS
release. When a reply containing an exception is received (for both sync and async send), the exception
handler notifies the user code but never releases the CAS. This may lead to hangs and may impact
performance since some CASes are never released.
(Continue reading)

Burn Lewis (JIRA | 4 Nov 17:44
Picon
Favicon

[jira] Updated: (UIMA-1119) The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the offending element.


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

Burn Lewis updated UIMA-1119:
-----------------------------

    Attachment: UIMA-1119-2.patch

UIMA-1119-2.patch replaces the previous one ... applies to the latest code with deltaCas support.

> The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the
offending element.
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: UIMA-1119
>                 URL: https://issues.apache.org/jira/browse/UIMA-1119
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>    Affects Versions: 2.2.2
>            Reporter: Burn Lewis
>            Priority: Minor
>         Attachments: UIMA-1119-2.patch, UIMA-1119.patch
>
>
> Obviously it's dangerous to edit XCASes but it is often the quickest way to produce a variety of test cases
for an annotator.  By changing a few lines we can report the invalid id.

--

-- 
(Continue reading)

Burn Lewis (JIRA | 4 Nov 17:46
Picon
Favicon

[jira] Updated: (UIMA-1119) The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the offending element.


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

Burn Lewis updated UIMA-1119:
-----------------------------

    Attachment:     (was: UIMA-1119.patch)

> The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the
offending element.
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: UIMA-1119
>                 URL: https://issues.apache.org/jira/browse/UIMA-1119
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>    Affects Versions: 2.2.2
>            Reporter: Burn Lewis
>            Priority: Minor
>         Attachments: UIMA-1119-2.patch
>
>
> Obviously it's dangerous to edit XCASes but it is often the quickest way to produce a variety of test cases
for an annotator.  By changing a few lines we can report the invalid id.

--

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

Picon
Favicon

[jira] Closed: (UIMA-1217) entityProcessComplete returns null CAS on error


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

Jerry Cwiklik closed UIMA-1217.
-------------------------------

    Resolution: Fixed

> entityProcessComplete returns null CAS on error
> -----------------------------------------------
>
>                 Key: UIMA-1217
>                 URL: https://issues.apache.org/jira/browse/UIMA-1217
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>    Affects Versions: 2.2.2
>            Reporter: Eddie Epstein
>         Attachments: uimaj-as-jms-UIMA-1217-patch-Release-2-2-2.txt, uimaj-as-jms-UIMA-1217-patch.txt
>
>
> Given that the UIMA AS client API caches outgoing CASes while waiting for a service reply, instead of
returning CAS=null on error, the outgoing CAS should be returned.

--

-- 
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-1191) Uima AS Reply Listener should be terminated when a delegate is disabled


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

Jerry Cwiklik closed UIMA-1191.
-------------------------------

    Resolution: Fixed

> Uima AS Reply Listener should be terminated when a delegate is disabled
> -----------------------------------------------------------------------
>
>                 Key: UIMA-1191
>                 URL: https://issues.apache.org/jira/browse/UIMA-1191
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-1191-patch.txt, uimaj-as-core-UIMA-1191-patch.txt
>
>
> If a remote delegate is disabled, its listener associated with a reply queue should be terminated. This
seems to be not working although there is code that supposed to stop the listener. If the listener is not
terminated, Spring attempts to recover the connection and dumps excessive exceptions into the log if the
remote broker is no longer available. An example stack trace is:
>  
> 9/24/08 2:20:55 AM - 17:
org.springframework.jms.listener.DefaultMessageListenerContainer.refreshConnectionUntilSuccessful:
INFO: Could not refresh JMS Connection - retrying in 20000 ms
> javax.jms.JMSException: Could not connect to broker URL: tcp://137.226.36.96:10008. Reason:
(Continue reading)

Picon
Favicon

[jira] Closed: (UIMA-1216) UIMA AS Client Code Doesn't Release CAS While Handling Process Exception


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

Jerry Cwiklik closed UIMA-1216.
-------------------------------

    Resolution: Fixed

> UIMA AS Client Code Doesn't Release CAS While Handling Process Exception
> ------------------------------------------------------------------------
>
>                 Key: UIMA-1216
>                 URL: https://issues.apache.org/jira/browse/UIMA-1216
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>         Attachments: uimaj-as-jms-UIMA-1216-patch-Release-2-2-2.txt, uimaj-as-jms-UIMA-1216-patch.txt
>
>
> UIMA AS client framework code caches a CAS before sending (async) request to UIMA AS service. When the
reply is received the CAS is retrieved from the cache, the client (user) code is called via a listener and
the CAS is subsequently released.  For synchronous calls the user code is responsible for each CAS
release. When a reply containing an exception is received (for both sync and async send), the exception
handler notifies the user code but never releases the CAS. This may lead to hangs and may impact
performance since some CASes are never released.

--

-- 
(Continue reading)

Picon
Favicon

[jira] Closed: (UIMA-844) Add connection recovery for temp queues in the JMS Listener object


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

Jerry Cwiklik closed UIMA-844.
------------------------------

    Resolution: Fixed

> Add connection recovery for temp queues in the JMS Listener object
> ------------------------------------------------------------------
>
>                 Key: UIMA-844
>                 URL: https://issues.apache.org/jira/browse/UIMA-844
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>    Affects Versions: 2.2.1
>            Reporter: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-844-patch.txt, uimaj-as-core-UIMA-844-patch.txt, uimaj-as-jms-UIMA-844-patch.txt
>
>
> When a connection to a temp queue is broken, the JMS listener is not set up to recover it. Part of the recovery
should be a creation of a new queue. 

--

-- 
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] Assigned: (UIMA-1119) The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the offending element.


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

Marshall Schor reassigned UIMA-1119:
------------------------------------

    Assignee: Marshall Schor

> The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the
offending element.
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: UIMA-1119
>                 URL: https://issues.apache.org/jira/browse/UIMA-1119
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>    Affects Versions: 2.2.2
>            Reporter: Burn Lewis
>            Assignee: Marshall Schor
>            Priority: Minor
>         Attachments: UIMA-1119-2.patch
>
>
> Obviously it's dangerous to edit XCASes but it is often the quickest way to produce a variety of test cases
for an annotator.  By changing a few lines we can report the invalid id.

--

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

Picon
Favicon

[jira] Commented: (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:comment-tabpanel&focusedCommentId=12645053#action_12645053
] 

Jerry Cwiklik commented on UIMA-1127:
-------------------------------------

If the client is an aggregate and the getMeta PING msg fails (due to timeout), should the aggregate apply an
action (disable/terminate/none) as defined in the DD for the delegate before returning exception back
to its client? 

> 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
>
> When a request times out, the service should be put into a "questionable" state. Requests to a service in
questionable state will then use a different logic: first send a getMeta request with a short timeout; if
the getMeta succeeds, the questionable state is removed and the normal request is sent; if getMeta fails,
an error is returned for the request with the state unchanged.
> This logic should be used for both API and aggregate clients.

(Continue reading)


Gmane