Return-Path: X-Original-To: apmail-oodt-dev-archive@www.apache.org Delivered-To: apmail-oodt-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E9F2C1179D for ; Wed, 6 Aug 2014 16:08:44 +0000 (UTC) Received: (qmail 47146 invoked by uid 500); 6 Aug 2014 16:08:44 -0000 Delivered-To: apmail-oodt-dev-archive@oodt.apache.org Received: (qmail 47112 invoked by uid 500); 6 Aug 2014 16:08:44 -0000 Mailing-List: contact dev-help@oodt.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@oodt.apache.org Delivered-To: mailing list dev@oodt.apache.org Received: (qmail 47100 invoked by uid 99); 6 Aug 2014 16:08:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Aug 2014 16:08:44 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of chris.a.mattmann@jpl.nasa.gov designates 128.149.139.109 as permitted sender) Received: from [128.149.139.109] (HELO mail.jpl.nasa.gov) (128.149.139.109) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Aug 2014 16:08:38 +0000 Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s76G8E6k017505 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Wed, 6 Aug 2014 09:08:17 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.111]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0195.001; Wed, 6 Aug 2014 09:08:11 -0700 From: "Mattmann, Chris A (3980)" To: "" Subject: Re: Multiple Processing Paradigms at Once Thread-Topic: Multiple Processing Paradigms at Once Thread-Index: AQHPsY4ujHW88/emekaSkiYDIUT97JvEL1oA//+OxkU= Date: Wed, 6 Aug 2014 16:08:10 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: chris.a.mattmann@jpl.nasa.gov X-AUTH: Authorized X-Virus-Checked: Checked by ClamAV on apache.org See OODT-215 and OODT-491 the functionality is not absent it is present and= those issues are the current status Sent from my iPhone > On Aug 6, 2014, at 8:53 AM, "Michael Starch" wrote: >=20 > Chris, >=20 > I believe I am working on the truck of OODT. The WEngine branch already > does what I need it to, however; the absence of this functionality in tru= nk > led me to wonder if this approach is undesired...hence this question. >=20 > -Michael >=20 >=20 > On Wed, Aug 6, 2014 at 8:50 AM, Chris Mattmann > wrote: >=20 >> Hi Mike, >>=20 >> I think you are using the wengine branch of Apache OODT. >> That is unmaintained. I would sincerely urge you to get >> this working in trunk, that's where the developers are working >> right now. >>=20 >> Cheers, >> Chris >>=20 >> P.S. Let me think more about the below I have some ideas there. >>=20 >> ------------------------ >> Chris Mattmann >> chris.mattmann@gmail.com >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Michael Starch >> Reply-To: >> Date: Wednesday, August 6, 2014 8:29 AM >> To: >> Subject: Multiple Processing Paradigms at Once >>=20 >>> All, >>>=20 >>> I am working on upgrading OODT to allow it to process streaming data, >>> alongside traditional non-streaming jobs. This means that some jobs ne= ed >>> to be run by the resource manager, and other jobs need to be submitted = to >>> the stream-processing. Therefore, processing needs to be forked or >>> multiplexed at some point in the life-cycle. >>>=20 >>> There are two places where this can be done: workflow manager runners, = and >>> the resource manager. Currently, I am working on building workflow >>> runners, and doing the job-multiplexing there because this cuts out one >>> superfluous step for the streaming jobs (namely going to the resource >>> manager before being routed). >>>=20 >>> Are there any comments on this approach or does this approach make sens= e? >>>=20 >>> -Michael Starch >>=20 >>=20 >>=20