Menu
▾
▴
bigdata-developers — List for bigdata developers
This list is closed, nobody may subscribe to it.
| 2010 |
Jan
|
Feb
(19) |
Mar
(8) |
Apr
(25) |
May
(16) |
Jun
(77) |
Jul
(131) |
Aug
(76) |
Sep
(30) |
Oct
(7) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
(16) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(7) |
Dec
(7) |
| 2012 |
Jan
(10) |
Feb
(1) |
Mar
(8) |
Apr
(6) |
May
(1) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(8) |
Dec
(2) |
| 2013 |
Jan
(5) |
Feb
(12) |
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(22) |
Aug
(50) |
Sep
(31) |
Oct
(64) |
Nov
(83) |
Dec
(28) |
| 2014 |
Jan
(31) |
Feb
(18) |
Mar
(27) |
Apr
(39) |
May
(45) |
Jun
(15) |
Jul
(6) |
Aug
(27) |
Sep
(6) |
Oct
(67) |
Nov
(70) |
Dec
(1) |
| 2015 |
Jan
(3) |
Feb
(18) |
Mar
(22) |
Apr
(121) |
May
(42) |
Jun
(17) |
Jul
(8) |
Aug
(11) |
Sep
(26) |
Oct
(15) |
Nov
(66) |
Dec
(38) |
| 2016 |
Jan
(14) |
Feb
(59) |
Mar
(28) |
Apr
(44) |
May
(21) |
Jun
(12) |
Jul
(9) |
Aug
(11) |
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2017 |
Jan
(20) |
Feb
(7) |
Mar
(4) |
Apr
(18) |
May
(7) |
Jun
(3) |
Jul
(13) |
Aug
(2) |
Sep
(4) |
Oct
(9) |
Nov
(2) |
Dec
(5) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bryan T. <br...@sy...> - 2010-07-20 15:36:27
|
Fred, Yes, I think that is a good idea. I know how this is done with CVS, but not with SVN. If you can track down how to do this, I will apply the changes on sourceforge. Sourceforge itself does post an RSS summary [2] of commits at the bottom of [1]. However, I also prefer to see this as email traffic. Thanks, Bryan [1] https://sourceforge.net/projects/bigdata/ [2] https://sourceforge.net/export/rss2_keepsake.php?group_id=191861 > -----Original Message----- > From: Fred Oliver [mailto:fko...@gm...] > Sent: Tuesday, July 20, 2010 11:31 AM > To: Bigdata Developers > Subject: [Bigdata-developers] Mailing lists for commit and trac? > > Bryan, > > Can you create sourceforge mailing lists for automatic > distribution of svn commit messages and trac issue creation > and updates? > > Fred > > -------------------------------------------------------------- > ---------------- > This SF.net email is sponsored by Sprint What will you do > first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Bigdata-developers mailing list > Big...@li... > https://lists.sourceforge.net/lists/listinfo/bigdata-developers > |
|
From: Fred O. <fko...@gm...> - 2010-07-20 15:30:56
|
Bryan, Can you create sourceforge mailing lists for automatic distribution of svn commit messages and trac issue creation and updates? Fred |
|
From: Fred O. <fko...@gm...> - 2010-07-20 14:59:12
|
On Tue, Jul 20, 2010 at 9:24 AM, Bryan Thompson <br...@sy...> wrote: > In this regard it is more flexible than an Jini system with support for creating global synchronous locks. I believe that global synchronous locks are more harmful than helpful, in general. That's why I would like to know how global synchronous locks help bigdata (not that zookeeper is a bad way to do it if necessary). > Services store their configuration state locally for restart in the service directory. However, we also need to know which persistent services exist, even if they are not running at the moment. That information is captured in zookeeper. For example, if the target #of logical data services (LDS) is 10, then we do not want to start a new data service if one goes down because the persistent state of the data service can be terabytes of files on local disks and is part of the semantics of its service "identity". I'm not clear about the problem you are describing. Say we have a DataService #5 configured one host H with a persistence directory D containing its UUID, journals, indices, etc. It is either running and registered with the lookup service (with the UUID) or not. If the service starter/manager on host H needs this service to be running and is not registered, start it. (There is a strictly local problem of starting a duplicate java process because of race conditions, but the service itself should detect and prevent that.) I don't see how global synchronization is involved here. Can you give another example of the need for global synchronization (excluding HA) or point out what I am missing? Fred |
|
From: Bryan T. <br...@sy...> - 2010-07-20 14:45:10
|
All, Once we close out the few remaining issues in the lexicon refactor branch [1,2], I would like to merge from the trunk to the branch to catch this branch up on evolution in the trunk. We can then do the merge to the trunk and close out this branch. We are planning a release which incorporates the lexicon refactor change set late this month. For people who have not been tracking this change set, the lexicon refactor will allow us to inline datatype literals. This should be a substantial advantage for numberic heavy data sets and aggregation style queries as we will can materialize the RDF Value objects directly from inlined datatype literals. This advantage is even larger in scale-out than in the standalone Journals. Please note that the lexicon refactor branch will break binary compatibility. The change set includes a significant change in the physical schema of the RDF database to permit the inlining of xsd datatype literals into the statement indices. In addition, there were a number of changes to the internal APIs as we moved from the assumption that the statement indices used long[3] or long[4] keys to variable length coding of a mixture of inlined RDF values and term identifiers as assigned by the lexicon. We are also going to move long RDF literals out of the ID2TERM index into raw records on the journal which will be migrated automatically to the index segments during overflow processing. The lexicon refactor change set has been validated againt the Journal implementations, but it will also need to be validated against a cluster. To that end, I suggest that we tag the trunk before we merge the lexicon refactor branch in to provide a checkpoint that people can use if we have any issues to resolve with the lexicon refactor on the cluster. Due to the changes in the physical schema, we were unable to avoid a binary compatibility break this time. However, we should be better positioned in the future for forward compatible changes. Given that we have a binary compatibility break with this change set, I plan to roll in a few other changes at the same time which would otherwise have caused problems with backward compatibility [3,4]. I will be mostly unavailable W/Th/F. Therefore, I would like to merge the lexicon branch back to the trunk either today or early next week. Thanks, Bryan [1] https://sourceforge.net/apps/trac/bigdata/ticket/59 [2] https://sourceforge.net/apps/trac/bigdata/ticket/109 [3] https://sourceforge.net/apps/trac/bigdata/ticket/107 [4] https://sourceforge.net/apps/trac/bigdata/ticket/41 |
|
From: Bryan T. <br...@sy...> - 2010-07-20 13:26:43
|
Fred, Bigdata uses zookeeper for: - configuration management. - synchronous distributed locks. - coordination of the service leader elections for HA. At this time, I believe that the only information persisted in zookeeper is the configuration metadata and the description of distributed jobs (such as the bulk loader). You can see all of this using the DumpZookeeper utility (dumpZoo.sh). I prefer to think of zookeeper as providing robust REST-like data transparency with preconditions on data updates and triggers. BrianM and I have discussed that capabilities for creating global synchronous locks and leader election patterns are available in some Jini distributions, but not in the open source Jini release that we are bundling. However, using Jini for this would only move the state from one distributed system to another, not eliminate "dead drops". Also, one of the attractive propositions of zookeeper is the ability to integrate distributed systems which share no other infrastructure and it supports a number of language bindings (C, Java, etc.) for that purpose. In this regard it is more flexible than an Jini system with support for creating global synchronous locks. Services store their configuration state locally for restart in the service directory. However, we also need to know which persistent services exist, even if they are not running at the moment. That information is captured in zookeeper. For example, if the target #of logical data services (LDS) is 10, then we do not want to start a new data service if one goes down because the persistent state of the data service can be terabytes of files on local disks and is part of the semantics of its service "identity". Likewise, in HA, we have to manage the decision to start a new physical data service (PDS) in a given bank of logical data services. For example, if we are going to update the installed s/w or h/w on a PDS, then we can schedule down time to differentiate it from a node failure. The LDS can maintain its quorum in the face of scheduled down time (e.g., 2 out of 3) without triggering the recruitment and synchronization of a new PDS instance for that LDS node. These are distinctions which could not be captured by local state on the node since the node could be powered off during a hardware update. Bryan > -----Original Message----- > From: Fred Oliver [mailto:fko...@gm...] > Sent: Monday, July 19, 2010 11:30 PM > To: Bigdata Developers > Subject: [Bigdata-developers] Why zookeeper? > > Why does bigdata use zookeeper? Isn't the bigdata system > more complex with zookeeper that it would be without? Or is > zookeeper going away as part of the "share nothing" effort? > > I have the impression that zookeeper is used for three things: > > Zookeeper appears to be used to communicate information > between bigdata services. (Like spies passing messages in > dead drops?) Wouldn't it be simpler and more straight forward > for services to ask each other for the information they need? > > Zookeeper appears to be used to persist data about each > service. Why wouldn't each service persist its own state, > privately? What is the benefit of allowing any service to see > another service's persisted state? > > Zookeeper has something to do with locks and synchronization? > What needs to be synchronized? For example, ticket #111 shows > that zookeeper is involved in preventing a DataService from > starting if a TransactionService is not running. But the > DataService should be robust enough to operate to some extent > even though the TransactionService fails or becomes > unreachable. And if the DataService is robust enough to wait > for the TransactionService to come online, why make this > artificial synchronization? > > Could zookeeper be evolved out of the system, simplifying the system? > > Thank you, > > Fred > > -------------------------------------------------------------- > ---------------- > This SF.net email is sponsored by Sprint What will you do > first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Bigdata-developers mailing list > Big...@li... > https://lists.sourceforge.net/lists/listinfo/bigdata-developers > |
|
From: Fred O. <fko...@gm...> - 2010-07-20 03:29:58
|
Why does bigdata use zookeeper? Isn't the bigdata system more complex with zookeeper that it would be without? Or is zookeeper going away as part of the "share nothing" effort? I have the impression that zookeeper is used for three things: Zookeeper appears to be used to communicate information between bigdata services. (Like spies passing messages in dead drops?) Wouldn't it be simpler and more straight forward for services to ask each other for the information they need? Zookeeper appears to be used to persist data about each service. Why wouldn't each service persist its own state, privately? What is the benefit of allowing any service to see another service's persisted state? Zookeeper has something to do with locks and synchronization? What needs to be synchronized? For example, ticket #111 shows that zookeeper is involved in preventing a DataService from starting if a TransactionService is not running. But the DataService should be robust enough to operate to some extent even though the TransactionService fails or becomes unreachable. And if the DataService is robust enough to wait for the TransactionService to come online, why make this artificial synchronization? Could zookeeper be evolved out of the system, simplifying the system? Thank you, Fred |
|
From: husdon <no...@no...> - 2010-07-19 19:01:31
|
See <http://localhost/job/BigData/changes> |
|
From: Bryan T. <br...@sy...> - 2010-07-19 12:06:23
|
Good morning, I would like everyone to review their issues in trac [1,2,3]. As of now, only two people have accepted issues, but there are many more people working on more issues. Please make sure that there is an active ticket for any work you are doing against the code base, whether in the trunk or a branch, and that you have "accepted" that ticket before you begin work on it. This will make it easier for us to track what is happening with concurrent development efforts and proactively avoid conflicting edits in the code base as much as possible. Thanks, Bryan [1] https://sourceforge.net/apps/trac/bigdata (bigdata trac instance). [2] https://sourceforge.net/apps/trac/bigdata/report/3 (Active, by milestone). [3] https://sourceforge.net/apps/trac/bigdata/report/4 (Accepted, by owner). |
|
From: Bryan T. <br...@sy...> - 2010-07-16 15:52:08
|
Brian, This currently blocking running unit tests against the federation on a single machine when that machine does not use eth0. Let's take up the issue of how to start services separately. Thanks, Bryan ________________________________ From: Brian Murphy [mailto:btm...@gm...] Sent: Friday, July 16, 2010 11:43 AM To: big...@li... Subject: Re: [Bigdata-developers] NicUtil On Fri, Jul 16, 2010 at 10:11 AM, Bryan Thompson <br...@sy...<mailto:br...@sy...>> wrote: Ah, my fault. It is LookupStarter on line #73 which references NicUtil using "eth0". Okay. For what it's worth, the original intent of the LookupStarter class was to provide a convenient utility for the build.xml to use to auto-start and auto-stop a lookup service that is external to the running of the junit tests themselves. It was never intended to be used in deployment. At some point I believe you moved that class from the test area to the bigdata source area. That fact, and the fact that there's commented out code in the JiniServicesHelper class that references LookupStarter, seems to imply that there's a possible/future intent to use that utility in the ServicesManagerService deployment mechanism. It would be my recommendation to not do this. Instead, I would recommend that the Jini ServiceStarter/NonActivatableServiceDescriptor mechanism continue to be used. BrianM |
|
From: husdon <no...@no...> - 2010-07-16 15:50:39
|
See <http://localhost/job/BigData/changes> |
|
From: Brian M. <btm...@gm...> - 2010-07-16 15:43:20
|
On Fri, Jul 16, 2010 at 10:11 AM, Bryan Thompson <br...@sy...> wrote: Ah, my fault. It is LookupStarter on line #73 which references NicUtil > using "eth0". > Okay. For what it's worth, the original intent of the LookupStarter class was to provide a convenient utility for the build.xml to use to auto-start and auto-stop a lookup service that is external to the running of the junit tests themselves. It was never intended to be used in deployment. At some point I believe you moved that class from the test area to the bigdata source area. That fact, and the fact that there's commented out code in the JiniServicesHelper class that references LookupStarter, seems to imply that there's a possible/future intent to use that utility in the ServicesManagerService deployment mechanism. It would be my recommendation to not do this. Instead, I would recommend that the Jini ServiceStarter/NonActivatableServiceDescriptor mechanism continue to be used. BrianM |
|
From: husdon <no...@no...> - 2010-07-16 14:36:23
|
See <http://localhost/job/BigData/75/> |
|
From: Bryan T. <br...@sy...> - 2010-07-16 14:12:36
|
Ah, my fault. It is LookupStarter on line #73 which references NicUtil using "eth0".
private static String thisHost = NicUtil.getIpAddress("eth0");
That is the bit which is unparameterized.
Thanks,
Bryan
________________________________
From: Brian Murphy [mailto:btm...@gm...]
Sent: Friday, July 16, 2010 9:35 AM
To: big...@li...
Subject: Re: [Bigdata-developers] NicUtil
On Thu, Jul 15, 2010 at 6:22 PM, Bryan Thompson <br...@sy...<mailto:br...@sy...>> wrote:
Could you please update NicUtil and the build.xml file to parameterize them for the ethernet interface? That value is currently a hardwired in NicUtil to "eth0".
Um, where do you see eth0 "hardwired" in NicUtil?
The only place where eht0 is mentioned in that class is
in one of the versions of the getInetAddress convenience
method; the version that allows one to pass in a Configuration,
and then defaults to eth0 if the given Configuration does
not specify an entry with the given entry name. Additionally,
as far as I can tell, that version of getInetAddress is never
called anywhere in the Bigdata code.
So it's not clear to me why you would characterize eth0 as
"hardwired".
I would like to see if I can get the federation to stand up on on a Windows Server machine by specifying the appropriate Ethernet interface in build.properties (I finally tracked down which interface is used by the Windows 2008 Server (eth3 in this specific case)).
When you say "get the federation to stand up on a Windows Server machine",
do you mean "use bigdataCluser(16).config/bigdataStandalone.config in
combination with 'bigdata start' to start the appropriate services", or do you
mean "run the tests on the Windows box using build.xml"?
Although I would generally have guessed that "stand up a federation"
refers to the former, the fact that you initially requested that "build.xml
be updated" makes me think that maybe you mean the latter.
If the former, I'm not sure what sort of "parameterization updates" you
think need to be made to NicUtil that would help you in that case;
especially given that bigdataCluser(16).config/bigdataStandalone.config
currently do not use NicUtil, but specify explicit IP addresses instead.
On the other hand, if it's the latter -- that is, if you want to run the tests
on Windows -- then I'm still not sure what you mean by "parameterization updates"
of either NicUtil or build.xml. Are you asking that a system property be
set when the junit target is executed that specifies the network interface
on which to export the services? Or something else?
If you are asking for a new system property in build.xml, then I'm still
not sure what this has to do with NicUtil. I believe such a system property
would affect only the test config files, not NicUtil. There are about five
test related config files that use eth0 as the network interface name, but
all but one of them fall back to local host if eth0 does not exist on the
system. The one config file that doen't fallback to local host may be
a bug; I'll have to look into it.
I wonder if we could find an "appropriate" default interface by testing all interfaces reported by NicUtil.getNetworkInterfaceArray("all") until we find one for which an IP address is returned by NicUtil.getIPAddress. Would that make any sense?
It might make sense, yes; especially in a development -- rather than deployment
scenario. In a deployment scenario, although I could imagine that there may
be some deployment scenarios where one doesn't care what interface(s) their
network traffic is sent over, it's been my experience that that is typically not
the case. So I would generally expect that one would want to explicitly
specify the network interface names in a real deployment, and fail fast if
one or more of the expected/specified interfaces are not available.
So I think your suggestion for adding a method that walks through
the network interfaces and returns an appropriate default IP may
be a useful convenience for development scenarios, but I'm still
not sure where the requested "parameterization" of NicUtil and
build.xml fits in with this suggestion.
With respect to deployment scenarios though, I caution anyone
who may be contemplating relaying on such a default mechanism
in their own real deployments; as I can assure you that we certainly
won't be deploying bigdata with default network interfaces.
Anyway, once I get a better sense of the problem, I'll start
investigating what sort of changes can/should be made.
BrianM
|
|
From: Brian M. <btm...@gm...> - 2010-07-16 14:06:38
|
On Thu, Jul 15, 2010 at 6:22 PM, Bryan Thompson <br...@sy...> wrote:
Could you please update NicUtil and the build.xml file to parameterize them
> for the ethernet interface? That value is currently a hardwired in NicUtil
> to "eth0".
Um, where do you see eth0 "hardwired" in NicUtil?
The only place where eht0 is mentioned in that class is
in one of the versions of the getInetAddress convenience
method; the version that allows one to pass in a Configuration,
and then defaults to eth0 if the given Configuration does
not specify an entry with the given entry name. Additionally,
as far as I can tell, that version of getInetAddress is never
called anywhere in the Bigdata code.
So it's not clear to me why you would characterize eth0 as
"hardwired".
I would like to see if I can get the federation to stand up on on a Windows
> Server machine by specifying the appropriate Ethernet interface in
> build.properties (I finally tracked down which interface is used by the
> Windows 2008 Server (eth3 in this specific case)).
>
When you say "get the federation to stand up on a Windows Server machine",
do you mean "use bigdataCluser(16).config/bigdataStandalone.config in
combination with 'bigdata start' to start the appropriate services", or do
you
mean "run the tests on the Windows box using build.xml"?
Although I would generally have guessed that "stand up a federation"
refers to the former, the fact that you initially requested that "build.xml
be updated" makes me think that maybe you mean the latter.
If the former, I'm not sure what sort of "parameterization updates" you
think need to be made to NicUtil that would help you in that case;
especially given that bigdataCluser(16).config/bigdataStandalone.config
currently do not use NicUtil, but specify explicit IP addresses instead.
On the other hand, if it's the latter -- that is, if you want to run the
tests
on Windows -- then I'm still not sure what you mean by "parameterization
updates"
of either NicUtil or build.xml. Are you asking that a system property be
set when the junit target is executed that specifies the network interface
on which to export the services? Or something else?
If you are asking for a new system property in build.xml, then I'm still
not sure what this has to do with NicUtil. I believe such a system property
would affect only the test config files, not NicUtil. There are about five
test related config files that use eth0 as the network interface name, but
all but one of them fall back to local host if eth0 does not exist on the
system. The one config file that doen't fallback to local host may be
a bug; I'll have to look into it.
> I wonder if we could find an "appropriate" default interface by testing all
> interfaces reported by NicUtil.getNetworkInterfaceArray("all") until we find
> one for which an IP address is returned by NicUtil.getIPAddress. Would that
> make any sense?
>
It might make sense, yes; especially in a development -- rather than
deployment
scenario. In a deployment scenario, although I could imagine that there may
be some deployment scenarios where one doesn't care what interface(s) their
network traffic is sent over, it's been my experience that that is typically
not
the case. So I would generally expect that one would want to explicitly
specify the network interface names in a real deployment, and fail fast if
one or more of the expected/specified interfaces are not available.
So I think your suggestion for adding a method that walks through
the network interfaces and returns an appropriate default IP may
be a useful convenience for development scenarios, but I'm still
not sure where the requested "parameterization" of NicUtil and
build.xml fits in with this suggestion.
With respect to deployment scenarios though, I caution anyone
who may be contemplating relaying on such a default mechanism
in their own real deployments; as I can assure you that we certainly
won't be deploying bigdata with default network interfaces.
Anyway, once I get a better sense of the problem, I'll start
investigating what sort of changes can/should be made.
BrianM
|
|
From: Bryan T. <br...@sy...> - 2010-07-16 12:33:53
|
Hello, Now that there is an increasing number of people working on the code base, I think that we need to improve our coordination somewhat so I (and others) can keep track of what is going on with the project. I am open to suggestions here, but it seems that the most scalable approach is to move to a model where people open and accept an issue before they touch the code and then keep the status updated on the accepted issues. We are also building up a list of more minor issues on trac which lack top-level categorization. Would someone like to step up to help maintain and impose order on the trac issues? The current organizational scheme uses "milestones" to capture high level areas of activity for the project, such as High Availability, Query Optimization, Performance Optimizations, etc. There is also an orthoginal set of components (Journal, Federation, RDF database, etc). Both of these could be refined somewhat to include additional distinctions. Thanks, Bryan |
|
From: Bryan T. <br...@sy...> - 2010-07-16 12:11:43
|
Ah. Yes, I was looking at another branch. I have not touched that code in ages so I had no expectation that there were any changes to the test suite. I see that three of the tests you wrote fail. The ring buffer is primarily used by the B+Tree and some other cache classes as a hard reference queue to force the retention of recently used references. Are any of these failures linked to higher level errors? Thanks, Bryan > -----Original Message----- > From: Bob Resendes [mailto:res...@ya...] > Sent: Friday, July 16, 2010 7:56 AM > To: Bryan Thompson; big...@li... > Subject: Re: [Bigdata-developers] Build failed in Hudson: BigData #70 > > Bryan, > > test_remove_get_order() is a new unit (as well as about 70 > others) that I added to TestRingBuffer.java and committed to > the trunk earlier this week. It was part of rev 3196 (see > > http://bigdata.svn.sourceforge.net/viewvc/bigdata?revision=319 > 6&view=revision) > and ticket #101 (see > https://sourceforge.net/apps/trac/bigdata/ticket/101) was > submitted to cover it. > > > I suspect that you haven't done an update to the latest > "trunk" code, yet, which is why you aren't seeing that > failure (or test) locally, but it is showing up in the CI builds. > > > Regards, > Bob > |
|
From: Bob R. <res...@ya...> - 2010-07-16 11:56:14
|
Bryan, test_remove_get_order() is a new unit (as well as about 70 others) that I added to TestRingBuffer.java and committed to the trunk earlier this week. It was part of rev 3196 (see http://bigdata.svn.sourceforge.net/viewvc/bigdata?revision=3196&view=revision) and ticket #101 (see https://sourceforge.net/apps/trac/bigdata/ticket/101) was submitted to cover it. I suspect that you haven't done an update to the latest "trunk" code, yet, which is why you aren't seeing that failure (or test) locally, but it is showing up in the CI builds. Regards, Bob |
|
From: Bryan T. <br...@sy...> - 2010-07-16 11:36:40
|
Here is another very odd artifact of the CI builds. The following test runs just fine in isolation on a local machine. However, the test failure is reported for a line number which does not exist in the code! The file is 423 lines long. The reported failure is at line 703.
This is extremely weird. I am going to (a) change hudson to use one build process (no concurrency) and (b) update hudson.
com.bigdata.cache.TestRingBuffer.test_remove_get_order (from TestRingBuffer)
Failing for the past 5 builds (Since Unstable#3 )
Took 2 ms.
add description
Error Message
expected same:<d> was not:<a>
Stacktrace
junit.framework.AssertionFailedError: expected same:<d> was not:<a>
at com.bigdata.cache.TestRingBuffer.test_remove_get_order(TestRingBuffer.java:703)
Bryan
> -----Original Message-----
> From: Bryan Thompson
> Sent: Thursday, July 15, 2010 3:45 PM
> To: big...@li...;
> fko...@us...
> Subject: RE: [Bigdata-developers] Build failed in Hudson: BigData #70
>
> All,
>
> This failure also appeared in another branch on the CI server
> which was running a build at the same time (the
> LEXICON_REFACTOR_BRANCH). Perhaps there is an interaction in
> the ant junit task when running two CI builds concurrently on
> the same machine?
>
> Thanks,
> Bryan
>
> > -----Original Message-----
> > From: husdon [mailto:no...@no...]
> > Sent: Thursday, July 15, 2010 3:31 PM
> > To: big...@li...;
> > fko...@us...
> > Subject: [Bigdata-developers] Build failed in Hudson: BigData #70
> >
> > See <http://localhost/job/BigData/70/changes>
> >
> > Changes:
> >
> > [fkoliver] Add test for decoding BTree keys built with JDK collator
> >
> > ------------------------------------------
> > [...truncated 589 lines...]
> > INFO : 3346822 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 3347499 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 3347544 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 3380656 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 3382079 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 3382346 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 3383809 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 3399939 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 3404329 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 3407614 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 3415187 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 3435999 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 3441304 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 3441585 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 3442421 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 3445519 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 3460006 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 3466972 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 3496076 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 3502250 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 3510873 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 3520071 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 3523426 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 3524467 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 3527038 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 3527763 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 3547293 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 3556173 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 3561486 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 3561754 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 3562336 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 3564092 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 3580146 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 3583508 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 3584542 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 3585941 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 3616252 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 3621561 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 3621834 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 3622663 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 3624173 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 3646738 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 3647195 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 3647910 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 3676343 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 3681282 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 3681642 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 3682501 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 3684255 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 3700280 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 3704698 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 3706098 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 3736424 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 3742013 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 3742581 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 3763722 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 3766165 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 3796500 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 3802097 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 3802922 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 3815158 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 3823802 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 3824835 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 3827413 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 3828129 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 3852286 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 3862739 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 3862995 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 3880493 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 3883878 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 3887480 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 3917187 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 3918391 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 3922257 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 3943961 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 3944986 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 3947551 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 3983924 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 3984738 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 4000657 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 4004059 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 4005055 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 4008365 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4042276 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 4042990 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 4044838 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 4050290 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 4065127 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 4066524 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 4067688 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4068433 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4081763 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 4102526 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 4103067 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 4117300 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 4120792 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 4127754 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4128501 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4151437 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 4157510 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4163394 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 4165033 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 4186671 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 4188221 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4222538 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 4222705 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 4245426 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 4246739 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 4248290 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4248643 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4277670 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4283551 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 4301007 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 4305517 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 4308357 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4327521 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 4337748 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4342874 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 4343448 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 4365602 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 4366876 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 4368424 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4393932 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 4397826 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4402783 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 4402954 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 4403544 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 4403712 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 4425689 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 4428489 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4428854 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4458668 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4463811 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 4465454 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 4487018 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 4488932 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4522941 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 4525536 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 4533343 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 4545873 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 4545874 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 4547087 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 4548653 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4549010 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4578886 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4583196 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 4585625 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 4601393 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 4608720 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4638968 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4643105 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 4666078 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 4667227 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 4669097 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4669167 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4671635 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 4692083 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 4699046 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4703210 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 4703372 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 4703950 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 4704125 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 4721527 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 4726158 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 4727293 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 4729239 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4759159 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4763296 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 4763458 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 4764045 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 4764211 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 4765904 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 4789314 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4812477 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 4819254 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4824122 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 4824288 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 4825988 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 4841667 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 4846331 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 4883469 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 4900698 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 4901748 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 4906406 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 4906407 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 4909388 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 4939448 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 4943544 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 4943772 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=863fc2fd-53ae-4a33-8c20-445b3534649d
> > INFO : 4953871 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 4961817 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 4966523 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 4966526 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 4967581 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 4970121 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 4970122 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 5006255 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 5021786 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 5026619 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 5026620 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 5030212 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 5030214 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 5040843 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 5059609 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 5064622 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 5086726 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 5087735 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=58c9ad65-31ee-4a87-99d8-138c318b32fd
> > INFO : 5114192 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 5123795 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 5124545 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 5124697 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=0d466515-a6c5-410b-8116-9c7c70b2754a
> > INFO : 5126416 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 5142047 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 5146786 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 5179788 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=5aec29be-7ef4-41dc-aa4d-98a9827e16f0
> > INFO : 5186510 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=9a5a1282-0cf5-40e7-b218-556dab388527
> > INFO : 5186666 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=1a1d52a2-249f-4b9f-b1de-6c58e5989c10
> > INFO : 5202112 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=27ea29bd-f687-485f-8ee3-f30f6147df0e
> > INFO : 5206858 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 5206885 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=3b1934f0-2ce6-4e35-8477-221bb7528295
> > INFO : 5210490 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=e9bf3231-3728-4870-9312-659ecaf295be
> > INFO : 5210501 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=8fa5bb70-f424-47cd-8e7c-37363d50d513
> > INFO : 5236388 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=afbd44f9-2df6-4bd7-82c6-72701ba41501
> > INFO : 5243987 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=24ae5cad-2875-4e94-b8d8-0149f8a3f97d
> > INFO : 5244715 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=7a9ada89-cad4-4648-9e2d-49bde37847b2
> > INFO : 5266938 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdata.service.LoadBalancerService.notify(LoadBalancerSer
> > vice.java:2239): serviceUUID=77b87cb4-2934-44f1-8917-eccb52a30026
> > INFO : 5270575 dutl-56.us.msudev.noklab.net
> > afbd44f9-2df6-4bd7-82c6-72701ba41501 (JSK) mux request
> > dispatch
> > com.bigdat...
[truncated message content] |
|
From: husdon <no...@no...> - 2010-07-15 23:35:34
|
See <http://localhost/job/BigData/changes> |
|
From: husdon <no...@no...> - 2010-07-15 22:29:03
|
See <http://localhost/job/BigData/changes> |
|
From: Bryan T. <br...@sy...> - 2010-07-15 22:23:29
|
Brian,
Could you please update NicUtil and the build.xml file to parameterize them for the ethernet interface? That value is currently a hardwired in NicUtil to "eth0". I would like to see if I can get the federation to stand up on on a Windows Server machine by specifying the appropriate Ethernet interface in build.properties (I finally tracked down which interface is used by the Windows 2008 Server (eth3 in this specific case)).
I wonder if we could find an "appropriate" default interface by testing all interfaces reported by NicUtil.getNetworkInterfaceArray("all") until we find one for which an IP address is returned by NicUtil.getIPAddress. Would that make any sense?
Thanks,
Bryan
> -----Original Message-----
> From: Brian Murphy
> Subject: Re: NicUtil
>
> ext Bryan Thompson wrote:
> > Brian,
> >
> > I am having a difficulty with NicUtil on a Windows Server
> 2008 machine.
> >
> > getIpAddressByLocalHost => 192.168.1.103
> >
> > getIpAddress eth0 => NIC_DOES_NOT_EXIST
> >
> > The machine has both IPv4 and IPv6 capability, but only
> IPv4 is setup.
> > It's using DHCP and I tried changing it to a dixed IP, but that did
> > not resolve the situation. Can you suggest what the
> problem might be?
>
> Yes, whereas the network names 'eth0', 'eth1', etc. are the
> common defaults on linux, Windows seems to do things
> differently. If you execute ipconfig on you Windows box, the
> output should display a line of the form:
>
> Ethernet adapter <589D05FD-D5A8-4054-B671-C12A19220CB9>
>
> It's been a while since I've looked at Windows, but I believe
> that if you were then to write some Java code that retrieved
> and displayed the network interface(s) on that box (for
> example, using NicUtil.getNetworkInterfaceArray("all")), you
> would see that the network interface name(s) that are
> displayed are of the form 'ethN' for some value of N; rather
> than the value ipconfig displays. If I recall correctly,
> somewhere deep down in the bowels of Java, it appears that
> Java does some sort of mapping from the ethernet adapter name
> that Windows knows to an 'ethN' form. Unfortunately, it seems
> that the algorithm Java uses to determine the value of N does
> not necessarily follow the order one would expect; that is, 0
> is not always the first value, followed by 1 for the next
> interface, and so on.
>
> For example, I recall a Windows node with 4 network
> interfaces in which Java mapped the interfaces to something
> like [eth11, eth15, eth16, and eth19].
>
> The use of 'eth0' was made the default to cover the common
> case; to minimize how often folks would have to determine and
> then supply a system's network interface name.
>
> For what it's worth, to address the Windows situation
> described above, I imagine one could write some additional
> code that determines if one is running on Windows, and then
> interprets 'eth0' as a desire to use the first interface,
> 'eth1' as the second interface, and so on. Since Windows
> isn't a requirement for DataOS though, I didn't focus on
> investigating such additional functionality.
>
> Brian
>
>
>
>
|
|
From: Bryan T. <br...@sy...> - 2010-07-15 21:58:56
|
Fred,
Answers below.
> bigdata/src/java/com/bigdata/btree/DefaultTupleSerializer.java:
> return new DefaultKeyBuilderFactory(new Properties());
^ The actual collator behavior will be captured by the IndexMetadata (the tuple serializer is saved as part of the IndexMetadata). You might add a warning to the constructor.
> bigdata/src/java/com/bigdata/btree/keys/KeyBuilder.java: return
> new DefaultKeyBuilderFactory(null/* properties */)
^ This is the specified behavior - it uses whatever is set in System.properties and otherwise defaults. You might add a warning to the constructor.
What is important for these first two cases is to make sure that we apply the Collator configuration as described for the specific index or triple store when it is created. So the use of these constructor forms could allow an unintended collator configuration to be inherited and made persistent as part of an index, triple store, etc. The critical case for the triple store is handled explicitly in LexiconRelation on line 644 (below) where it uses the properties used to create the AbstractTripleStore to setup the collator for the TERM2ID index. This is the only triple store index which can have Unicode data in the key, and hence the only one for which the collator configuration can have any impact. All of the rest of the indices are based on non-text data in the keys.
protected IndexMetadata getTerm2IdIndexMetadata(final String name) {
final IndexMetadata metadata = newIndexMetadata(name);
metadata.setTupleSerializer(new Term2IdTupleSerializer(getProperties()));
return metadata;
}
> bigdata/src/java/com/bigdata/btree/NOPTupleSerializer.java:
> new DefaultKeyBuilderFactory(new Properties()));
^ This should have no impact. The tuple serializer is not used in this case.
> bigdata/src/java/com/bigdata/journal/Name2Addr.java:
> new DefaultKeyBuilderFactory(new Properties())));
^ This one is worth doing something about. The role of Name2Addr is to map from index names to the address of a checkpoint record for the named index. The journals in the federation really should all have a consistent behavior in this regard otherwise bizarre errors could creep in with different collators on different nodes. E.g., you could have two index names which one node believed to be distinct while another node was using a collator which did not capture the distinction. For this, I think that the only "fix" is to put the information into the service configuration information so the data services and the metadata service all share the same collator configuration (all services can share, but these are the ones which could cause a problem).
Can you file an issue on this?
Thanks,
Bryan
> -----Original Message-----
> From: Fred Oliver [mailto:fko...@gm...]
> Sent: Thursday, July 15, 2010 5:39 PM
> To: Bryan Thompson
> Cc: Bigdata Developers
> Subject: Re: [Bigdata-developers] BTree key mismatch questions
>
> On Thu, Jul 15, 2010 at 4:29 PM, Bryan Thompson
> <br...@sy...> wrote:
> > Fred,
> >
> >> Yes, please add that locale to the sample configuration files. I
> >> think it should be made reasonably obvious that the locale of the
> >> machine and the locale of the data need not be related.
> >
> > If you don't mind, can you apply and test the edit. If you
> look in the configuration file (bigdataStandalone.config,
> bigdataCluster.config, bigdataCluster16.config), you will see
> the following line in each file. It is part of the section
> where we are declaring the properties that will be applied to
> the triple store created by the batch job:
> >
> > new NV(BigdataSail.Options.COLLATOR,"ASCII"),
> >
> > You should be able to just specify additional properties
> right there to override the locale, collator, etc. The
> BigdataSail.Options is just inheriting options which include
> KeyBuilder.Options, so all of the options should be
> accessible in the BigdataSail.Options namespace. You can
> also explictly reference them in the KeyBuilder.Options
> namespace if you feel that is clearer (but make sure to
> import that namespace at the top of the configuration file).
>
> OK. That covers a few of the cases (maybe the important
> ones). But there are DefaultKeyBuilderFactories created with
> empty or null properties objects:
>
> bigdata/src/java/com/bigdata/btree/DefaultTupleSerializer.java:
> return new DefaultKeyBuilderFactory(new Properties());
> bigdata/src/java/com/bigdata/btree/keys/KeyBuilder.java: return
> new DefaultKeyBuilderFactory(null/* properties */)
> bigdata/src/java/com/bigdata/btree/NOPTupleSerializer.java:
> new DefaultKeyBuilderFactory(new Properties()));
> bigdata/src/java/com/bigdata/journal/Name2Addr.java:
> new DefaultKeyBuilderFactory(new Properties())));
>
> What are the consequences of unfortunate collators or locales
> in these places?
>
> Fred
>
|
|
From: Fred O. <fko...@gm...> - 2010-07-15 21:39:01
|
On Thu, Jul 15, 2010 at 4:29 PM, Bryan Thompson <br...@sy...> wrote: > Fred, > >> Yes, please add that locale to the sample configuration >> files. I think it should be made reasonably obvious that the >> locale of the machine and the locale of the data need not be related. > > If you don't mind, can you apply and test the edit. If you look in the configuration file (bigdataStandalone.config, bigdataCluster.config, bigdataCluster16.config), you will see the following line in each file. It is part of the section where we are declaring the properties that will be applied to the triple store created by the batch job: > > new NV(BigdataSail.Options.COLLATOR,"ASCII"), > > You should be able to just specify additional properties right there to override the locale, collator, etc. The BigdataSail.Options is just inheriting options which include KeyBuilder.Options, so all of the options should be accessible in the BigdataSail.Options namespace. You can also explictly reference them in the KeyBuilder.Options namespace if you feel that is clearer (but make sure to import that namespace at the top of the configuration file). OK. That covers a few of the cases (maybe the important ones). But there are DefaultKeyBuilderFactories created with empty or null properties objects: bigdata/src/java/com/bigdata/btree/DefaultTupleSerializer.java: return new DefaultKeyBuilderFactory(new Properties()); bigdata/src/java/com/bigdata/btree/keys/KeyBuilder.java: return new DefaultKeyBuilderFactory(null/* properties */) bigdata/src/java/com/bigdata/btree/NOPTupleSerializer.java: new DefaultKeyBuilderFactory(new Properties())); bigdata/src/java/com/bigdata/journal/Name2Addr.java: new DefaultKeyBuilderFactory(new Properties()))); What are the consequences of unfortunate collators or locales in these places? Fred |
|
From: Bryan T. <br...@sy...> - 2010-07-15 20:29:36
|
Fred,
> Yes, please add that locale to the sample configuration
> files. I think it should be made reasonably obvious that the
> locale of the machine and the locale of the data need not be related.
If you don't mind, can you apply and test the edit. If you look in the configuration file (bigdataStandalone.config, bigdataCluster.config, bigdataCluster16.config), you will see the following line in each file. It is part of the section where we are declaring the properties that will be applied to the triple store created by the batch job:
new NV(BigdataSail.Options.COLLATOR,"ASCII"),
You should be able to just specify additional properties right there to override the locale, collator, etc. The BigdataSail.Options is just inheriting options which include KeyBuilder.Options, so all of the options should be accessible in the BigdataSail.Options namespace. You can also explictly reference them in the KeyBuilder.Options namespace if you feel that is clearer (but make sure to import that namespace at the top of the configuration file).
> Otherwise, if different machines (containing different shards or
> clients) in a single cluster had different locale settings,
> then would all the machines be creating or processing keys in
> a single BTree with the same locale?
Yes, they would still be using the same locale regardless of their local settings. The locale of the IKeyBuilder that will be used for the index is fixed when the index is created. Otherwise just changing the Locale on the machine could render the data in the index unreadable!
> If BTree indices are split and shards moved to machines with
> different locale settings, then will the IndexMetadata object
> on both machines necessarily agree? What is the origin of the
> (content of the) IndexMetadata object?
The origin is the IndexMetadata with which the B+Tree was originally created. For scale-out, the IndexMetadata template is stored in the MetadataService. Each time a local B+Tree object is created for a shard the same IndexMetadata object is applied to that new B+Tree object. So the local IndexMetadata is consistent with the original settings. (You have to do extra work if you want to propagate a change to the IndexMetadata for all shards of a scale-out index).
Thanks,
Bryan
PS: I am trying to see if I can work around that JDK collator issue with the embedded nulls in the Unicode sort keys. The underlying problem is that we can't find the start of the column name, not that the column name itself can not be decoded.
> -----Original Message-----
> From: Fred Oliver [mailto:fko...@gm...]
> Sent: Thursday, July 15, 2010 4:18 PM
> To: Bryan Thompson
> Cc: Bigdata Developers
> Subject: Re: [Bigdata-developers] BTree key mismatch questions
>
> On Thu, Jul 15, 2010 at 12:47 PM, Bryan Thompson
> <br...@sy...> wrote:
> > Fred,
> >
> > I think that the local of the machine should control the
> default since
> > it is more likely to be correct and more transparent with
> the OS/Java
> > stack. You can specify this in the bigdataCluster.config file for
> > scale-out or the Properties for a Journal. I am happy to
> specify en_US
> > in the sample configuration files. That makes it pretty
> obvious where
> > people can override this behavior.
>
> Yes, please add that locale to the sample configuration
> files. I think it should be made reasonably obvious that the
> locale of the machine and the locale of the data need not be related.
>
> Otherwise, if different machines (containing different shards or
> clients) in a single cluster had different locale settings,
> then would all the machines be creating or processing keys in
> a single BTree with the same locale?
>
> >> The choice of language appears to be left to default system
> >> properties which can also vary from VM to VM.
> >
> > The choice is made based on the local environment, but it
> is captured
> > by the IndexMetadata object and imposed on any machine
> which uses that index.
>
> If BTree indices are split and shards moved to machines with
> different locale settings, then will the IndexMetadata object
> on both machines necessarily agree? What is the origin of the
> (content of the) IndexMetadata object?
>
> Fred
>
|
|
From: Fred O. <fko...@gm...> - 2010-07-15 20:17:57
|
On Thu, Jul 15, 2010 at 12:47 PM, Bryan Thompson <br...@sy...> wrote: > Fred, > > I think that the local of the machine should control the default since it is > more likely to be correct and more transparent with the OS/Java stack. You > can specify this in the bigdataCluster.config file for scale-out or the > Properties for a Journal. I am happy to specify en_US in the sample > configuration files. That makes it pretty obvious where people can override > this behavior. Yes, please add that locale to the sample configuration files. I think it should be made reasonably obvious that the locale of the machine and the locale of the data need not be related. Otherwise, if different machines (containing different shards or clients) in a single cluster had different locale settings, then would all the machines be creating or processing keys in a single BTree with the same locale? >> The choice of language appears to be left to default system properties >> which can also vary from VM to VM. > > The choice is made based on the local environment, but it is captured by the > IndexMetadata object and imposed on any machine which uses that index. If BTree indices are split and shards moved to machines with different locale settings, then will the IndexMetadata object on both machines necessarily agree? What is the origin of the (content of the) IndexMetadata object? Fred |
27 messages has been excluded from this view by a project administrator.
