Mailing-List: contact uima-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: uima-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of eaepstein@gmail.com designates
 209.85.132.247 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Na1habzZRSCqUxqqDcoGKd9rTF2LK0M/sii0KgR14cxQdOGvoX6n2awhcpUyuCV9H0CHCFsLjSKaBJemVkJAtxJsKtVdHb39L9xLNnMeUTEBRmNEwD4qX5jrMgRu9xu2S6RkcEeIz9BRXqCJCmGw7YbByMLcQWQwGJp4sT6ahCU=
Message-ID: <cd6edfd30705211322m51973cdesaf372a3cef22aefa@mail.gmail.com>
Date: Mon, 21 May 2007 16:22:47 -0400
From: "Eddie Epstein" <eaepstein@gmail.com>
To: uima-dev@incubator.apache.org
Subject: Re: Eddie - can you check my reasoning on this "bug" in setting the
 CASImpl sofaRef?
In-Reply-To: <4651DE10.9040107@schor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4651DE10.9040107@schor.com>

On 5/21/07, Marshall Schor <msa@schor.com> wrote:
> The resetNoQuestions iterates over all the views, calling resetView:
>
>   /*
>    * iterated reset - once per view of a CAS except for the base CAS
>    */
>     private void resetView() {
>         this.indexRepository.flush();
>         if (this.mySofaRef > 0 && this.getSofa().getSofaRef() == 1) {
>             // indicate no Sofa exists for the initial view
>             this.mySofaRef = -1;
>         } else {
>             this.mySofaRef = 0;
>         }
>
> ...
>
> The logic for resetting this.mySofaRef should be to set it to -1 for the
> initial view, and 0 for other cases
> The -1 indicates no sofa has been created (lazy creation being done).
>
> But this logic seems to fail when CAS Pools are being set up because the
> pools are created, each CAS having
> a base and an "initial View" with the mySofaRef set to -1 for the
> initial view.  So far, so good.
> The pool creation code contains  a call to:
>
>   protected void populateCasToCasPoolMap(CasPool aCasPool) {
>     CAS[] casArray = new CAS[aCasPool.getSize()];
>     for (int i = 0; i < casArray.length; i++) {
>       casArray[i] = ((CASImpl) aCasPool.getCas()).getBaseCAS();
>       mCasToCasPoolMap.put(casArray[i], aCasPool);
>     }
>     for (int i = 0; i < casArray.length; i++) {
>       aCasPool.releaseCas(casArray[i]);
>     }
>   }
>
> which just is there to set up a map from the cas to the pool to which it
> belongs.  It however, works by
> checking out each cas, and then releasing them back.  The releaseCas
> calls "reset" on the CAS.  This
> causes the above resetView to be called on the initial view, but the
> sofa has never been created.  So the
> bit of logic trying to detect this is the initial sofa, fails, and the
> mySofaRef is set to 0.  Later when the initial
> view is checked out of the pool, the lazy sofa creation mechanism fails
> because it requires mySofaRef be -1.
>
> Note this would fail anytime a CAS initial view was acquired, and reset
> called on it prior to doing anything which
> would have required that a sofa be created.
>
> I'm fixing this by having the caller of resetView, which knows
> explicitly which sofa is the initial one, handle this
> by setting mySofaRef to -1 there.  Does this seem right?
>
> -Marshall
>

That would work. Or you could just fix resetView() with:

	if (this.mySofaRef > 0) {
          if (this.getSofa().getSofaRef() == 1) {
		// indicate no Sofa exists for the initial view
		this.mySofaRef = -1;
	  } else {
		// indicate no Sofa exists
		this.mySofaRef = 0;
	  }
	}