Return-Path: Delivered-To: apmail-incubator-river-dev-archive@minotaur.apache.org Received: (qmail 44015 invoked from network); 19 Jan 2011 10:18:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 19 Jan 2011 10:18:44 -0000 Received: (qmail 16771 invoked by uid 500); 19 Jan 2011 10:18:44 -0000 Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org Received: (qmail 16641 invoked by uid 500); 19 Jan 2011 10:18:42 -0000 Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: river-dev@incubator.apache.org Delivered-To: mailing list river-dev@incubator.apache.org Received: (qmail 16633 invoked by uid 99); 19 Jan 2011 10:18:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jan 2011 10:18:41 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dan.creswell@gmail.com designates 209.85.216.175 as permitted sender) Received: from [209.85.216.175] (HELO mail-qy0-f175.google.com) (209.85.216.175) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jan 2011 10:18:34 +0000 Received: by qyk8 with SMTP id 8so397763qyk.6 for ; Wed, 19 Jan 2011 02:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=s3tJeKdCiWca/fJ5fCDXdLcEYvALwAKBvtnSqHo8DeY=; b=SMAlbqAJESjqWdWFIkywlK+IF0EoatN0NPsSw5cXoM6X4yMDzExEFyHMXRQQm7xYp0 I4SfiqbIw4dzG0c1cxH2kMcGjakP5JBYqL0kOKw03XDOz+bKfE3O84es8CPlYi2BUOWO DOST0USaZhfwZ7nGOn+z3j25or/9CK3yCRDVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=YpSj4rKLt9AEAmXIcZu8TPlaOC0JXT6ppArGnoUnCGr0hbtmV4bsdxqIBBngsA+xfc eus4QfYcu9FpyLtaEH2p1cuH3gC3/6/l8VDDeCvXd3r9Su6zNhWOoSR3lcotvft9SaJ6 HvByOJFOsNBcPjWTW+gYr4wijV+rHLHcfYkyU= MIME-Version: 1.0 Received: by 10.224.80.148 with SMTP id t20mr506248qak.286.1295432292939; Wed, 19 Jan 2011 02:18:12 -0800 (PST) Received: by 10.220.181.201 with HTTP; Wed, 19 Jan 2011 02:18:12 -0800 (PST) In-Reply-To: <4D36B663.7020909@zeus.net.au> References: <1293009549.81923193@192.168.2.228> <1293044231.999312361@192.168.2.228> <4D361678.90301@simulexinc.com> <4D363F47.3090103@simulexinc.com> <4D3698B8.40509@acm.org> <4D36B663.7020909@zeus.net.au> Date: Wed, 19 Jan 2011 10:18:12 +0000 Message-ID: Subject: Re: Space/outrigger suggestions (remote iterator vs. collection) From: Dan Creswell To: river-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=0015175ce1b6a6b7d0049a305555 X-Virus-Checked: Checked by ClamAV on apache.org --0015175ce1b6a6b7d0049a305555 Content-Type: text/plain; charset=ISO-8859-1 On 19 January 2011 10:01, Peter Firmstone wrote: > Dan Creswell wrote: > >> Note too that iterator does not support remote semantics whereas MatchSet >> does (all those explicit RemoteExceptions etc). >> >> An iterator as defined for the Java platform might fail for concurrency >> reasons (although notably it doesn't for many of the modern concurrent >> collections) or because an operation (typically remove) is not supported. >> >> > Yes I bumped into this recently when creating a concurrent policy > implementation, although it was with Enumeration, the backing set cannot be > modified while the Enumeration is being read from a loop, the same with the > iterator. :) > When access large disk records and pulling these into memory, you typically > only take a small chunk, process it and move on, so the behaviour is more > stream like, rather than iterator, I created an interface called > ResultStream (yes it supports Generics, but beware the compilation > boundaries that haven't been checked by the compiler), result stream is > terminated by a null value. > > That's generally similar to how MatchSet works under the covers.... > package org.apache.river.api.util; > > /** > * This interface is similar to an Enumerator, it is designed to return > * results incrementally in loops, however unlike an Enumerator, there is no > * check first operation as implementors must return a null value after > * the backing data source has been exhausted. So this terminates like a > stream > * by returning a null value. > * > * @author Peter Firmstone > */ > public interface ResultStream { > /** > * Get next T, call from a loop until T is null; > * @return T unless end of stream in which case null is returned. > */ > public T get(); > So this overall, isn't far from where MatchSet goes. For those following along, remoteness issues are such that we can't reliably return null to indicate "end of stream". One may never reach the end of the stream if there's a failure at the back-end. One could counter that with a "wait for the failure to go away" scenario but that assumes the failure does go away and it might not (and whilst you're figuring all that out your thread is blocked and can't say much to your upstream users). In essence, then returning null means "we successfully reached the end of the stream". And we need some other mechanism to say "we didn't reach the end of the stream for some reason". Typically the mechanism is an exception.... > /** > * Close the result stream, this allows the implementer to close any > * resources prior to deleting reference. > */ > public void close(); > > } > > --0015175ce1b6a6b7d0049a305555--