Satya,
Did you get a clean build? You'd expect to see something like this:
[INFO] uima-ducc-parent .. SUCCESS [
7.309 s]
[INFO] Apache UIMA DUCC: uima-ducc-user .. SUCCESS [
6.986 s]
[INFO] Apache UIMA DUCC: uima-ducc-common
It is also possible that RM prediction has decided that additional
processes are not needed. It
appears that there were likely 64 work items dispatched, plus the 6
completed, leaving only
30 that were idle. If these work items appeared to be completing
quickly, the RM would decide
that
An excellent question by Lou.
Been wracking my brains over what would cause the agent instability and
this would absolutely do it.
What will likely happen if you try to run 2 DUCCs on the same machines
if you don't change the broker
port, is the second DUCC will see the broker alive and
Amit,
The component that decides when it's time to scale out is the DUCC
Resource Manager, or RM.
The decision to scale out is made essentially from a combination of
(a) how much work is left, (b) how long work items take to complete, and
(c) how long it takes to initialize a new
Reshu,
If this is the same issue you mentioned in the Jira it's possible
that the Agent isn't able to properly shutdown. You can get around this
by issuing
check_ducc -k
after
stop_ducc -a
As a rule of thumb, I like to stop ducc by issuing check_ducc -k a
few times
. ducc_ling is back-compatible quite a ways, so if you're
still on a pre 1.0.0 version, it should be safe to get the 1.0.0
ducc_ling, patch it, and install it in the beta.
Jim
On 2/14/14 9:25 AM, Jim Challenger wrote:
Erdem,
Sorry, I'd only been watching the devlist up to now
