Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of pats@acm.org designates
 209.86.89.70 as permitted sender)
Message-ID: <4D46BD1E.5070307@acm.org>
Date: Mon, 31 Jan 2011 05:46:06 -0800
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Question about JavaSpaces functionality
References: <4D462FAD.2000707@acm.org>
 <150C2A96-D183-44F7-A12B-12072564E7FC@topiatechnology.com>
 <4D464FDA.5010109@acm.org>
 <207E7289-B3AB-4C4D-856E-E7C524672B56@topiatechnology.com>
 <4D46568D.4030409@acm.org>
 <3ACF9E3C-212B-4336-8D49-CDF81E84C0B6@topiatechnology.com>
In-Reply-To: <3ACF9E3C-212B-4336-8D49-CDF81E84C0B6@topiatechnology.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

False alarm. Outrigger uses a FastList for template management, as well 
as for storing the actual entries. The late FastList adds all relate to 
templates, and the last entry add is before the first write task starts 
up. The writes are complete before the first read. This differs from my 
original bug, which related to subjecting FastList to a mix of 
concurrent adds and removes.

The bad news is that it looks as though the test is correct. I have 
failed to break the current FastList implementation even running extreme 
unit test loads overnight. The difficult aspects of FastList are now 
delegated to java.util.concurrent.ConcurrentLinkedQueue, which I believe 
is extremely well tested and reviewed.

That all means I need to dig into the guts of outrigger to find why some 
reads are failing, instead of just looking at the reasonably simple 
FastList and StressTest classes. :-(

Patricia


On 1/30/2011 10:33 PM, Mike McGrady wrote:
> This is important.  Good sleuthing
>
> Sent from my iPhone
>
> Michael McGrady
> Principal investigator AF081_028 SBIR
> Chief Architect
> Topia Technology, Inc
> Work 1.253.572.9712
> Cel 1.253.720.3365
>
> On Jan 30, 2011, at 10:28 PM, Patricia Shanahan<pats@acm.org>  wrote:
>
>> Just that I'm seeing indications that the reads and writes may be getting mixed up together, and wanted to be sure I'm debugging the right end of the problem.
>>
>> On 1/30/2011 10:26 PM, Mike McGrady wrote:
>>> I agree and am not sure why you have doubts?
>>>
>>> Sent from my iPhone
>>>
>>> Michael McGrady
>>> Principal investigator AF081_028 SBIR
>>> Chief Architect
>>> Topia Technology, Inc
>>> Work 1.253.572.9712
>>> Cel 1.253.720.3365
>>>
>>> On Jan 30, 2011, at 9:59 PM, Patricia Shanahan<pats@acm.org>   wrote:
>>>
>>>> I wish it had been phrased in the same terms as the JLS. I know the write call completion happens-before the call to the read method. I think that means the same as "the write returns before the read commences" but I'm not sure.
>>>>
>>>> Patricia
>>>>
>>>>
>>>>
>>>>
>>>> MICHAEL MCGRADY wrote:
>>>>> There is this, which I assume you have already seen?
>>>>> Operation Ordering
>>>>> Operations on a space are unordered. The only view of operation order can be a thread's view of the order of the operations it performs. A view of inter-thread order can be imposed only by cooperating threads that use an application-specific protocol to prevent two or more operations being in progress at a single time on a single JavaSpaces service. Such means are outside the purview of this specification.
>>>>> For example, given two threads T and U, if T performs a write operation and U performs a read with a template that would match the written entry, the read may not find the written entry even if the write returns before the read. Only if T and U cooperate to ensure that the write returns before the read commences would the read be ensured the opportunity to find the entry written by T (although it still might not do so because of an intervening take from a third entity).
>>>>> On Jan 30, 2011, at 7:42 PM, Patricia Shanahan wrote:
>>>>>> Suppose thread A writes an item to a JavaSpace, thread B attempts to read it, and A's call to the space's proxy write method happens-before B's call to the space's proxy read method. There are no transactions involved
>>>>>>
>>>>>> Should the read always succeed?
>>>>>>
>>>>>> In other words, should a happens-before relationship between two actions in a client imply a corresponding happens-before relationship between the corresponding actions in the actual space, without depending on transaction semantics?
>>>>>>
>>>>>> This question affects whether I'm working on a bug in outrigger or in one of its tests.
>>>>>>
>>>>>> Thanks for any information.
>>>>>>
>>>>>> Patricia
>>>>> Michael McGrady
>>>>> Chief Architect
>>>>> Topia Technology, Inc.
>>>>> Cel 1.253.720.3365
>>>>> Work 1.253.572.9712 extension 2037
>>>>> mmcgrady@topiatechnology.com
>>>>
>>>
>>
>