Mailing-List: contact uima-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: uima-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of eaepstein@gmail.com
 designates 64.233.184.229 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=C+ptqdfdgHY8m/SW8mwsTFtARRVuH9pblEzlkeDOMSHCKkZFSqqAVOmEXZMeZLpMb0ElESiJUL2989IlR5mRCcheX8b3DyApafuKA8OnKlBD6Meq4vSJWeDv1LZEBp2QZQoimHXTuTPR+4fPsFUcTvNywPkaog3jk+3hd6Dsqdw=
Message-ID: <cd6edfd30804291311v49cd912fw2f95c45a2123969a@mail.gmail.com>
Date: Tue, 29 Apr 2008 16:11:58 -0400
From: "Eddie Epstein" <eaepstein@gmail.com>
To: uima-user@incubator.apache.org
Subject: Re: Server Socket Timeout Woes
In-Reply-To: <BLU124-W1472F1EC44AF30121B7E4A95D90@phx.gbl>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3586_28699496.1209499918180"
References: <6.2.1.2.2.20080422153419.084ef4d8@mail.llnl.gov>
	 <2787e08a0804221938q4a8771d4hcf4e717f06af9828@mail.gmail.com>
	 <6.2.1.2.2.20080423133753.0add1700@mail.llnl.gov>
	 <2787e08a0804231444n3ba0f448ib8e2720aab4bb86b@mail.gmail.com>
	 <BLU124-W1472F1EC44AF30121B7E4A95D90@phx.gbl>

------=_Part_3586_28699496.1209499918180
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Vinci has scalability limitations for the reasons you describe below. In
case you are not aware, there is a new scalability layer, UIMA AS, which is
on the verge of being ready for release. UIMA AS uses ActiveMQ for the
communications layer, providing both proper load balancing and dynamic
addition/subtraction of service instances. Some other features of UIMA AS:

   - includes all of the error handling logic in the CPM and more
   - fully supports the UIMA flow controller
   - enables replication for individual AEs, not just entire CPE
   pipelines
   - no code changes required for Apache UIMA components
   - supports C++ annotators running as native processes, no Java wrapper
   required

Wish it were out already. Trying hard.
Eddie

On Tue, Apr 29, 2008 at 1:22 PM, Charles Proefrock <chas.pro@hotmail.com>
wrote:

> I'm excited to see this thread for it's affirmation that someone has
> pushed Vinci scalability to the point that Steve has at LLNL.  Also, to know
> the currently released version has some limitations.  At the risk of
> diverting this thread, let me share what we've found.
>
> I'm on board with Adam's line of thinking.  We've just spent 2 weeks
> experimenting with the various options for exclusive/random allocation of
> Vinci services, finding that 'exclusive' is the most reliable way to balance
> load (random sometimes hands all of the clients the same service while other
> services go unused).  The phrase "when a service is needed" isn't clear in
> the documentation.  As Adam indicated, our finding is that "need" occurs
> only at client thread initialization time as opposed to each process(CAS)
> call.  Additionally, "exclusive" is not exactly clear, as two client threads
> can be handed the same service if the number of services available are less
> than the number of threads initializing.  This behavior is robust (better to
> get a remote than have nothing allocated), but it isn't clear from our
> relatively small setup (two threads, two remotes) what the word 'exclusive'
> means or how large a system can get before 'exclusive' pans out as the
> right/wrong approach.
>
> In the face of services starting/stopping on remote computers (e.g.,
> during multi-platform reboot), there seems to be no way to robustly take
> advantage of additional services coming on-line.  If "when needed" meant
> each process(CAS) call (as an option at least ... to trade the re-connect
> negotiation overhead for dynamic scalability), then a system that
> initializes to 5 remotes can balance out as 10,20,30 remotes come online.
>  For now, we are using the CPE 'numToProcess' parameter to exit the CPE,
> then construct a new CPE and re-enter the process() routine to seek out new
> services periodically.
> Also, we are seeing a startup sequence that sometimes results in the first
> document sent to each remote returning immediately with a connection/timeout
> exception ... so we catch those items and re-submit them at the end of the
> queue in case they really did exit due to a valid timeout exception.
>
> Any feedback/collaboration would be appreciated.
>
> - Charles
>
>

------=_Part_3586_28699496.1209499918180--