Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0BCE1CCB5 for ; Fri, 27 Apr 2012 01:31:30 +0000 (UTC) Received: (qmail 13641 invoked by uid 500); 27 Apr 2012 01:31:29 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 13597 invoked by uid 500); 27 Apr 2012 01:31:29 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 13583 invoked by uid 99); 27 Apr 2012 01:31:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Apr 2012 01:31:29 +0000 X-ASF-Spam-Status: No, hits=2.0 required=5.0 tests=SPF_NEUTRAL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 216.139.236.26 is neither permitted nor denied by domain of mccabejj@gmail.com) Received: from [216.139.236.26] (HELO sam.nabble.com) (216.139.236.26) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Apr 2012 01:31:23 +0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SNa1W-00009y-0D for users@camel.apache.org; Thu, 26 Apr 2012 18:31:02 -0700 Date: Thu, 26 Apr 2012 18:31:02 -0700 (PDT) From: mccabejj To: users@camel.apache.org Message-ID: <1335490262000-5669042.post@n5.nabble.com> In-Reply-To: References: <1335407813277-5666526.post@n5.nabble.com> Subject: Re: Http Route with WireTap -- Question/Issue MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks Claus. You are correct the messages are stream based, and the behavior I've noticed seems to fit in precisely with the http://camel.apache.org/stream-caching.html documentation . Per your advice I have tried reconfiguring both the Camel Context and the individual routes to have streamCache="true" (both the main route and the WireTap). Unfortunately in both cases the behavior was the same. A varying % of the transactions end up not logging due to an empty body. A certain % also end up returning an empty or partial HTTP response to the client. If I disable "logging" by removing the WireTap everything processes normally. I have verified this using SOAPUI assertions. Lastly it seems that the failure % goes up the faster the transactions process. A simple thing like changing the log level to WARN instead of DEBUG will have an impact. I feel like I've got this configured correctly, but there must be something I'm missing. One thing I may try is moving the processor that prepares the message for logging to the WireTap instead of in the LogRequest route per the http://camel.apache.org/wire-tap.html documentation (either by using processorRef or onPrepareRef). I'm not sure if that would make a difference or not. Let me know if there are other suggestions or comments. Thanks all. JM -- View this message in context: http://camel.465427.n5.nabble.com/Http-Route-with-WireTap-Question-Issue-tp5666526p5669042.html Sent from the Camel - Users mailing list archive at Nabble.com.