Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 739A6200C1D for ; Thu, 2 Feb 2017 03:54:53 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 6F3D9160B5E; Thu, 2 Feb 2017 02:54:53 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 8F76B160B46 for ; Thu, 2 Feb 2017 03:54:52 +0100 (CET) Received: (qmail 90169 invoked by uid 500); 2 Feb 2017 02:54:51 -0000 Mailing-List: contact dev-help@fluo.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@fluo.incubator.apache.org Delivered-To: mailing list dev@fluo.incubator.apache.org Received: (qmail 90158 invoked by uid 99); 2 Feb 2017 02:54:51 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2017 02:54:51 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 4D0D8189FB6 for ; Thu, 2 Feb 2017 02:54:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id i6HmSMcnk9za for ; Thu, 2 Feb 2017 02:54:49 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with SMTP id C678A5F177 for ; Thu, 2 Feb 2017 02:54:48 +0000 (UTC) Received: (qmail 90081 invoked by uid 99); 2 Feb 2017 02:54:18 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2017 02:54:18 +0000 Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com [209.85.217.174]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 1A2841A002B for ; Thu, 2 Feb 2017 02:54:18 +0000 (UTC) Received: by mail-ua0-f174.google.com with SMTP id i68so2326909uad.0 for ; Wed, 01 Feb 2017 18:54:17 -0800 (PST) X-Gm-Message-State: AIkVDXIiJL3pkd0lmSCBw2+5/bwox7RIGNo8NhPFrEkonWoVK4e6WP1x3z+LMRCT+rA4BOX1d+x5+r+QMYTS5A== X-Received: by 10.159.33.213 with SMTP id 79mr2500349uac.32.1486004057151; Wed, 01 Feb 2017 18:54:17 -0800 (PST) MIME-Version: 1.0 References: <4ce0516a7eca4d78a6e1e25bf3481d39@ALHUN12EXCH02.Parsons.com> <1485961333946.54190@parsons.com> In-Reply-To: <1485961333946.54190@parsons.com> From: Christopher Date: Thu, 02 Feb 2017 02:54:06 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: third party service to poll Fluo for absence of event To: dev@fluo.incubator.apache.org Content-Type: multipart/alternative; boundary=001a113df78ef6272005478347bc archived-at: Thu, 02 Feb 2017 02:54:53 -0000 --001a113df78ef6272005478347bc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 1, 2017 at 10:04 AM Meier, Caleb wrote: > Yeah, this seems pretty reasonable to me. I guess it then boils down to > the nitty gritty of do I store results in Fluo and have my service query > Fluo (I think you guys actually advise against that in your documentation= ), > or export results and then have the service query some external index tha= t > I am exporting to. > > I'm not sure we advise against it, so much as recognize that it may not be suitable for certain use cases and may not meet query performance expectations ( http://fluo.apache.org/docs/fluo-recipes/1.0.0-incubating/export-queue/). In any case, your observer need not write the final "last occurrence" entries into a Fluo table. It could write them anywhere. > Regarding timestamps, does the oracle server provide actual timestamps or > just logical timestamps? That is, could I use the timestamps that the > server provides to define some sort of now() function to obtain the curre= nt > time to compare with the times of incoming events? > Just logical time, and it delivers batches to limit locking, so it can appear to jump ahead spontaneously. I'm not sure the OracleServer is suitable for this purpose. What level of precision are you going for? It might be enough to just run NTP, if you don't need more precision than "within seconds". > ________________________________________ > From: Christopher > Sent: Tuesday, January 31, 2017 5:08 PM > To: dev@fluo.incubator.apache.org > Subject: Re: third party service to poll Fluo for absence of event > > You could write an observer which rolls up timestamps from all the events > you are concerned about, and puts the most recent event timestamp into a > centralized place, which you could poll. If there is no ingest of these > events, then the last timestamp in this central place will exceed some > threshold and the poller could detect that and trigger additional actions= . > > On Tue, Jan 31, 2017 at 3:51 PM Meier, Caleb > wrote: > > > Hello, > > > > I=E2=80=99m looking into using Fluo to develop an event based notificat= ion system > > that incrementally generates events of increasing complexity. The one > > issue that I=E2=80=99m running into is how to handle the non-event even= t. That > is, > > Fluo (as I understand it) is not well-suited to handle the following > > request: =E2=80=9Cgenerate a notification if no events of a given type = have > > occurred within the last 24 hours=E2=80=9D. This is because it is a pu= sh based > > notification framework that only generates notifications when things > > actually happen. So the question is, has anyone looked into developing= a > > service for generating notifications at regular intervals (even if > > something doesn=E2=80=99t happen) that works with Fluo? I=E2=80=99m to= ying with the idea > > of creating some sort of Twill application that tells Fluo to wake up a= t > > regular intervals to generate a notification about the set of events > > falling within the given time window. Before doing this I just wanted t= o > > make sure that something like this does not already exist, and I also > want > > to get a sense of how bad an idea it is to delegate some of the logic o= f > > this periodic notification service to Fluo. Would it be better to > > separate out the temporal portion of my notification request to be > > processed entirely outside of Fluo to avoid transactional overhead? > > > > Caleb A. Meier, Ph.D. > > Software Engineer II =E2=99=A6 Analyst > > Parsons Corporation > > 1911 N. Fort Myer Drive, Suite 800 =E2=99=A6 Arlington, VA 22209 > > Office: (703)797-3066 <(703)%20797-3066> <(703)%20797-3066> > > Caleb.Meier@Parsons.com =E2=99=A6 > www.parsons.com< > > http://www.parsons.com/> > > > > -- > Christopher > --=20 Christopher --001a113df78ef6272005478347bc--