In theory ,it could do some help.
On Sat, Jun 5, 2010 at 9:10 PM, Jonathan Ellis wrote:
> From what I have read, allowing the reference to be GC'd itself is
> equivalent to calling clear. Does adding clear() make an observable
> difference?
>
> On Sat, Jun 5, 2010 at 1:31 AM, Anty wrote:
> > -
I just didn't know if there were any way to make it easier for the non-java
crowd to take advantage of it. I'll give it some more thought.
On Jun 8, 2010, at 4:05 PM, Jonathan Ellis wrote:
> exposing it through thrift would mean the path would be
>
> client
> to cassandra [processing thrift co
Java transports buffer internally. there is no TBufferedTransport the
way there is in C#.
(moving to user@)
On Tue, Jun 8, 2010 at 10:31 AM, Subrata Roy wrote:
> We are using Cassandra 0.6.2 with hector/thrift client, and our
> application performance is really slow. We are not sure that it is
exposing it through thrift would mean the path would be
client
to cassandra [processing thrift command]
to hadoop [giving it a job]
to cassandra [fetching the data]
to hadoop [m/r]
to cassandra [handing result back]
to client
it just doesn't seem like a good design to me.
additionally, thrift is
When I gave a presentation on cassandra+hadoop, some ruby folks were wondering
about the possibility of using the MapReduce functionality in a language other
than Java.
I was just wondering if any thought was given to exposing the
org.apache.cassandra.hadoop functionality through thrift. That
We are using Cassandra 0.6.2 with hector/thrift client, and our
application performance is really slow. We are not sure that it is
because of hector/thrift connection or not. Jonathan E. and other
people has suggested that using "TBuffferedTransport(TSocket) instead of
a TSocket directly" perform
Are the restrictions on column family names specified anywhere? I see that
hyphens aren't allowed, and I assume anything else that wouldn't work in a
filename? I assume that underscores, commas, and periods are allowed?
Thanks
Ed
On Jun 4, 2010, at 7:57 PM, Eric Evans wrote:
>
>> i think the best possible solution would be for cassandra to be
>> maintained as a release quality package in debian unstable, with all
>> external java dependencies packaged separately and available in debian
>> unstable as well, but the cassan
I'm curious if there are any efforts ongoing to amortize the
background tasks in Cassandra over time?
Specifically, the cost of compaction and AE, rebalancing, etc seems to
be a problem for some users when they are expecting more steady-state
performance. While this may sometimes be the result of a
