The M/R job over the http api seems to be working to me.
curl -X POST http://192.168.1.39:8098/mapred -H "Content-Type:
application/json" -d @query.json
query.json:
{"inputs":{"bucket":"mentions","index":"docUID_bin","key":"5b9d1a6250dbd3e77ff004a12d06958745ee32844ad4aa668001bbe69b5efcf8"},"query":[{"reduce":{"language":"erlang","module":"riak_kv_mapreduce","function":"reduce_identity","arg":"{reduce_phase_only_1,
true}"}}]}
Results:
[["mentions","1907d031c88b8df2fc5128114615133d4184cedaea55964c3cee0ef9fe566f13"],["mentions","1bb5ce4aba0bf240698876530948c807d50e6f04a7358b7514c756dd295775ae"],["mentions","1f5f8f78951c6842ad6bcc96e3839ca8240b71372d2ab4826411fdfc84fedeb1"],["mentions","330856dabfa3a1c5b9ca8051686d8d7f387a23c795493a4e8f33d84861756d4f"],["mentions","338fffb9740b2f0c50b2da52a73b4861be318868082db3748eb95a47654981bd"],["mentions","5eef2b9cd6f7faf34548c9700069527287574690ab3dabf4c4f186753ffc5417"],["mentions","7ec9217a7a87c9e43a94170bb1ab8c13566233823ef6f77ef9c455a289c4bdf8"],["mentions","a588d7f0fb413d52a895a5d7e7fcfc966e9a56c42456e7821d2e5fa93b5671ba"],["mentions","aaacde92acf2c61abf9a4104f263283aed6233da08efb6ebbf13f83dfcfa1e7c"]]
Looks good to me. It has an extra "mentions" term, but I think the java
client explicitly drops that when converting the m/r results.
Alex
On Tue, Oct 25, 2011 at 9:12 AM, Russell Brown <russel...@basho.com> wrote:
>
> On 25 Oct 2011, at 13:58, Alexander Robbins wrote:
>
> Thanks for the classpath tip. That was it.
>
> Ok, using the HTTP client I don't get the same weird results. (It is
> noticeably slower, but that is to be expected I think.)
>
>
> Ok, cool (sort off).
>
> Would it be too much trouble if I asked you to run the following M/R job
> using the HTTP API, using curl, so I can narrow things down further still?
> If you just insert *your* bucket, index and value:
>
> curl -X POST http://127.0.0.1:8098/mapred -H "Content-Type:
> application/json" -d @-
>
> {"inputs":{"bucket":"YOUR_BUCKET_PLEASE","index":"YOUR_INDEX_PLEASE","key":"YOUR_VALUE_PLEASE"},"query":[{"reduce":{"language":"erlang","module":"riak_kv_mapreduce","function":"reduce_identity","arg":"{reduce_phase_only_1,
> true}"}}]}
>
>
> It would really help figure out at what point the problem is. If this M/R
> works OK then I'll raise a bug against the Java client.
>
> Cheers
>
> Russell
>
>
> Alex
>
> On Mon, Oct 24, 2011 at 4:11 PM, Russell Brown <russel...@basho.com>wrote:
>
>>
>> On 24 Oct 2011, at 21:56, Alexander Robbins wrote:
>>
>> Hey, sorry for the delay. I'm having trouble switching to the HTTP client.
>> I'm getting this error whenever I try to use it: (Using riak java client
>> version 1.0.1)
>>
>> org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager: method
>> <init>()V not found
>>
>>
>> Caused by:
>>
>> java.lang.NoSuchMethodError:
>> org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager: method
>> <init>()V not found
>> at
>> com.basho.riak.client.http.util.ClientUtils.newHttpClient(ClientUtils.java:77)
>> at
>> com.basho.riak.client.http.util.ClientHelper.<init>(ClientHelper.java:71)
>> at com.basho.riak.client.http.RiakClient.<init>(RiakClient.java:62)
>> at com.basho.riak.client.http.RiakClient.<init>(RiakClient.java:58)
>> at
>> com.basho.riak.client.raw.http.HTTPRiakClientFactory.newClient(HTTPRiakClientFactory.java:75)
>> ...
>>
>>
>> This is the setup code I'm using for the HTTP client:
>> client = HTTPRiakClientFactory.getInstance().newClient(
>> new HTTPClientConfig.Builder().withHost("192.168.1.92").build())
>>
>>
>> You can shorten this to
>>
>> RiakFactory.newClient( new
>> HTTPClientConfig.Builder().withHost("192.168.1.92").build())
>>
>> i.e. you don't need to use the specific factory directly, RiakFactory will
>> select the correct factory for the type of config it is given.
>>
>>
>> I don't see how I could be causing that error. Any ideas?
>>
>>
>> Classpath issue. You have an older HTTP Client jar on your class path,
>> 4.0.x. The 4.1.1 Apache HTTP Client that the RJC depends on has a no-arg
>> TSCM constructor, the 4.0.x release did not.
>>
>>
>> Alex
>>
>> On Mon, Oct 24, 2011 at 3:02 PM, Russell Brown <russel...@basho.com>wrote:
>>
>>>
>>> On 24 Oct 2011, at 20:21, Alexander Robbins wrote:
>>>
>>> > Using a new Riak 1.0 cluster.
>>> >
>>> > We added data in with a secondary index. When getting the data back out
>>> the results list is odd.
>>> >
>>> > [null, null, null, null, null, null, null, null, null, null, null,
>>> null, null, null, null, null, null, null, null, null, a, c, 9, d, 9, 1, d,
>>> d, 0, e, 5, 5, 6, 8, c, 6, d, 4, 8, f,
>>> e1b865342e2d81fac6b99dfa157dd8550ecc0b68caad2fb55c12e9fa5b1532c2,
>>> 85dca536068b8ead86c14c009c8a919457d2326419c16e0cd7f3b23a8776e2c8,
>>> be2f346c56827912cc4e21b765bd28d520a46833d08b8207ca6b49c8da2351d2,
>>> 1907d031c88b8df2fc5128114615133d4184cedaea55964c3cee0ef9fe566f13,
>>> 1bb5ce4aba0bf240698876530948c807d50e6f04a7358b7514c756dd295775ae,
>>> 1f5f8f78951c6842ad6bcc96e3839ca8240b71372d2ab4826411fdfc84fedeb1,
>>> 330856dabfa3a1c5b9ca8051686d8d7f387a23c795493a4e8f33d84861756d4f,
>>> 338fffb9740b2f0c50b2da52a73b4861be318868082db3748eb95a47654981bd,
>>> 5eef2b9cd6f7faf34548c9700069527287574690ab3dabf4c4f186753ffc5417,
>>> 7ec9217a7a87c9e43a94170bb1ab8c13566233823ef6f77ef9c455a289c4bdf8,
>>> a588d7f0fb413d52a895a5d7e7fcfc966e9a56c42456e7821d2e5fa93b5671ba,
>>> 767655d6443a337b2d3d89c0d1c38c3bac62398b74e0deef572508c54a2ad8b1,
>>> 7ca77aa38e44942d769ab8b08753b008ad65fe5d0d8c6438b67849381300aa9f,
>>> ab0a791a5a82345c5adce2c0d0d9013bab176e430d335228355781aa23a87f3e,
>>> b42af37baa18e715ca64a7145783cd3fd0defa9b2dc18368ec4c647cbe710132,
>>> c4d9c7b2cd837294cca10a581976a3f6d93d74cb2d30cac48384c64fc0bb6e2c,
>>> c7c10ad62091e3c7ba304d8a58f02c180c76f47d8d1d4addb21b9a88da277e75,
>>> 127f5b7255d61fcf0477a53d242c248cca824d9e60dafffc244d8e9df2bf7cbf,
>>> 23636fa4ef8af2a1d26335a3c8daca24ec5cd7978ee2429615e2b60538d6c9e9,
>>> 385d59cc404d3c7f097b2ae9e0e82768ac980c9ba157f6ea77d91ad49e812469, [,
>>> mentions, 50c2c9983e2ea3806c6d5e34a19ed526844945d0a06c70557695dfaa15b70ba3]
>>> >
>>> > The 64 character strings are good. They exist in riak and can be
>>> loaded. The other results make less sense. null, a, c, 9, [, and "mentions"
>>> aren't valid keys. Any ideas what might have happened that the results from
>>> a fetchIndex would have invalid keys? There are always 20 null responses and
>>> 20 single character responses. The single character responses vary from
>>> request to request. The "[" and "mentions" keys show up every time too. I'm
>>> confused here, because I don't think this could be me adding bad data. This
>>> list should be valid keys, as determined by riak, right?
>>>
>>> They should be valid keys, yes. To help narrow the issue down, could you
>>> run the same query using the Java HTTP Client, please? The HTTP Client uses
>>> the HTTP 2i endpoint, whereas the PB client uses map/reduce behind the
>>> scenes.
>>>
>>> Cheers
>>>
>>> Russell
>>>
>>> >
>>> > There is a possibility that another bucket has index values with
>>> multibyte characters. Could that be breaking results in a separate bucket.
>>> >
>>> > Thanks in advance,
>>> > Alex
>>> > _______________________________________________
>>> > riak-users mailing list
>>> > riak-users@lists.basho.com
>>> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>>
>>>
>> _______________________________________________
>> riak-users mailing list
>> riak-users@lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>>
>>
>
>
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
