Return-Path: Delivered-To: apmail-incubator-uima-dev-archive@minotaur.apache.org Received: (qmail 92483 invoked from network); 3 Aug 2009 17:33:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Aug 2009 17:33:34 -0000 Received: (qmail 92208 invoked by uid 500); 3 Aug 2009 17:33:39 -0000 Delivered-To: apmail-incubator-uima-dev-archive@incubator.apache.org Received: (qmail 92161 invoked by uid 500); 3 Aug 2009 17:33:39 -0000 Mailing-List: contact uima-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: uima-dev@incubator.apache.org Delivered-To: mailing list uima-dev@incubator.apache.org Received: (qmail 92151 invoked by uid 99); 3 Aug 2009 17:33:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Aug 2009 17:33:39 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Aug 2009 17:33:36 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id ED23B234C046 for ; Mon, 3 Aug 2009 10:33:14 -0700 (PDT) Message-ID: <208076522.1249320794970.JavaMail.jira@brutus> Date: Mon, 3 Aug 2009 10:33:14 -0700 (PDT) From: "Jerry Cwiklik (JIRA)" To: uima-dev@incubator.apache.org Subject: [jira] Commented: (UIMA-1454) Stale requests are processed and subsequently labeled as exceptions In-Reply-To: <674270336.1248377714815.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/UIMA-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738442#action_12738442 ] Jerry Cwiklik commented on UIMA-1454: ------------------------------------- There are two possibilities for not being able to deliver a reply. One is when the client goes away but the broker is running.The current code seems to handle this already. The code logs 2 lines that look something like this: 8/3/09 1:12:16 PM - 11: org.apache.uima.adapter.jms.activemq.JmsEndpointConnection_impl.handleJmsException: INFO: >>>> Controller: NoOp Annotator - Failed to Send Message To Queue: : temp-queue://ID:host2-3436-1249319511048-3:0:1. The Queue Has Been Deleted. 8/3/09 1:12:16 PM - 11: org.apache.uima.adapter.jms.activemq.JmsOutputChannel.dispatch: INFO: Controller: NoOp Annotator Failed Sending Reply To Remote Destination Managed By Server: tcp://localhost:61616 Queue: ID:host2-3436-1249319511048-3:0:1 Second scenario is when the broker managing a reply queue is stopped. In this case, indeed the UIMA AS service throws Exceptions to stdout and the log. Need to modify the code to silence this a bit and replace it with a two log lines, one highlighting connection problem and the second, to show that a reply could not be delivered for a given CAS. Remaining is the optimization to prevent processing a request if the reply queue is known to be dead. A new list holding dead reply queues is needed and a cleanup thread that will manage entries in that list. > Stale requests are processed and subsequently labeled as exceptions > ------------------------------------------------------------------- > > Key: UIMA-1454 > URL: https://issues.apache.org/jira/browse/UIMA-1454 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout > Reporter: Eddie Epstein > > When a client submits one or more requests to a service and then terminates > before the service has a chance to reply, the service will still process the requests > and then fail trying to send the reply with a long stack trace. > There are two problems here: processing a request which cannot be replied to, > and throwing an exception for expected behavior. > The following is suggested: > 1. catch these exceptions and log a single line at INFO level that a reply could > not be sent to {identified reply queue name} > 2. put this reply queue on a "do not process" list to be checked before processing > new requests. > 3. clean up the "do not process" list based on time or max number of entries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.