uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Proefrock <chas....@hotmail.com>
Subject RE: Server Socket Timeout Woes
Date Wed, 30 Apr 2008 21:12:42 GMT
Thanks for the heads-up.  I'm new to the Apache world ... Is there a repository of requirements
or a component functional description for UIMA-AS, or does an interested party need to join
the dev group and download the project to access this material?
Need to provide honest assessments of the technology to users, and propose next steps ...
so information is always helpful.In any event, always good to see something better come along
that has the words "no code changes required" associated with it ;)
Thanks for your efforts,

> Date: Tue, 29 Apr 2008 16:11:58 -0400> From: eaepstein@gmail.com> To: uima-user@incubator.apache.org>
Subject: Re: Server Socket Timeout Woes> > 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>
>> >
Make i'm yours.  Create a custom banner to support your cause.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message