use promise to handle stubleupon deferred instead of pool of futures

[koertkuipers]

No description provided.

[rubanm]

@koertkuipers thanks for the PR. I gather there is no way to do this without breaking existing clients, since the threads arg is no longer needed.

The tests seem to be failing:

14/08/12 22:10:58 WARN datanode.DataNode: Invalid directory in dfs.data.dir: Incorrect permission for /home/travis/build/twitter/storehaus/target/test-data/5e973952-89a7-46fe-8b59-7b9567fc161e/dfscluster_ab5cee0f-d644-4e92-8e3d-75531c341f10/dfs/data/data1, expected: rwxrwxr-x, while actual: rwxr-xr-x

14/08/12 22:10:58 WARN datanode.DataNode: Invalid directory in dfs.data.dir: Incorrect permission for /home/travis/build/twitter/storehaus/target/test-data/5e973952-89a7-46fe-8b59-7b9567fc161e/dfscluster_ab5cee0f-d644-4e92-8e3d-75531c341f10/dfs/data/data2, expected: rwxrwxr-x, while actual: rwxr-xr-x
14/08/12 22:10:58 ERROR datanode.DataNode: All directories in dfs.data.dir are invalid.

[error] Could not run test com.twitter.storehaus.hbase.HBaseStringStoreProperties: java.lang.ExceptionInInitializerError

@MansurAshraf any idea what may have caused this? needs more permissions? develop seems clean.

[koertkuipers]

we could keep an unused threads args? or wait for next major release with
this pullreq

HBaseTestingUtility creates directories with the default umask, which
varies by computer, and then expects the particular permissions for
directories set in dfs.datanode.data.dir.perm or else fails. the tests
failed for me, so i changed the expected permissions to reflect my umask:
conf.set("dfs.datanode.data.dir.perm", "775")

On Sat, Aug 23, 2014 at 2:41 PM, Ruban Monu notifications@github.com
wrote:

@koertkuipers https://github.com/koertkuipers thanks for the PR. I
gather there is no way to do this without breaking existing clients, since
the threads arg is no longer needed.

The tests seem to be failing:

14/08/12 22:10:58 WARN datanode.DataNode: Invalid directory in dfs.data.dir: Incorrect permission for /home/travis/build/twitter/storehaus/target/test-data/5e973952-89a7-46fe-8b59-7b9567fc161e/dfscluster_ab5cee0f-d644-4e92-8e3d-75531c341f10/dfs/data/data1, expected: rwxrwxr-x, while actual: rwxr-xr-x

14/08/12 22:10:58 WARN datanode.DataNode: Invalid directory in dfs.data.dir: Incorrect permission for /home/travis/build/twitter/storehaus/target/test-data/5e973952-89a7-46fe-8b59-7b9567fc161e/dfscluster_ab5cee0f-d644-4e92-8e3d-75531c341f10/dfs/data/data2, expected: rwxrwxr-x, while actual: rwxr-xr-x
14/08/12 22:10:58 ERROR datanode.DataNode: All directories in dfs.data.dir are invalid.

[error] Could not run test com.twitter.storehaus.hbase.HBaseStringStoreProperties: java.lang.ExceptionInInitializerError

@MansurAshraf https://github.com/MansurAshraf any idea what may have
caused this? needs more permissions? develop seems clean.

—
Reply to this email directly or view it on GitHub
#238 (comment).

[johnynek]

can we delete the "h" in asynch for consistincy with stumbleupon.async?

[johnynek]

sorry for the delay. We are working up the stack to convert to scala 2.10 + 2.11. If we can get this green, I'd love to get it in.

On the fence about the binary break. We could add the dummy integer, but only if we have no other binary incompatibility along the stack (bijection changed binary compat, and this depends on bijection, so...)

[johnynek]

Any idea why this fails?

In any case, you can get it green by disableing 2.9 support in .travis.yml and making 2.10.4 the default build. We finally switched to 2.10 at Twitter, so we plan to build this for 2.10 and 2.11 now.

[koertkuipers]

it fails in 2.9 because I am using scala 2.10+ stuff like value classes,
anticipating upgrade to 2.10/2.11
On Sep 5, 2014 7:56 PM, "P. Oscar Boykin" notifications@github.com wrote:

Any idea why this fails?

In any case, you can get it green by disableing 2.9 support in .travis.yml
and making 2.10.4 the default build. We finally switched to 2.10 at
Twitter, so we plan to build this for 2.10 and 2.11 now.

—
Reply to this email directly or view it on GitHub
#238 (comment).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}