This is a known issue with the Cassandra 0.6 versions of Pelops. The issue was fixed in the 0.7 based versions a few months ago but never back-ported (Dominic, myself and the other contributors don't run 0.6)...
On 24 January 2011 05:25, cbert...@libero.it <cbert...@libero.it> wrote: > > Reconnect and try again? > > Sorry what do you mean by "Reconnect and try again?" -- You mean to shut > down the old pool and create a new pool of connections? > I don't have the possibility to handle the single connection using Pelops > ... > > From Dominic Williams Blog > > "To work with a Cassandra cluster, you need to start off by defining a > connection pool. This is typically done once in the startup code of your > application" > [...] > "One of the key design decisions that at the time of writing distinguishes > Pelops, is that the data processing code written by developers does not > involve connection pooling or management. Instead, classes like Mutatorand > Selector borrow connections to Cassandra from a Pelops pool for just the > periods that they need to read and write to the underlying Thrift API. This > has two advantages. > > Firstly, obviously, code becomes cleaner and developers are freed from > connection management concerns. But also more subtly this enables the Pelops > library to completely manage connection pooling itself, and for example keep > track of how many outstanding operations are currently running against each > cluster node. > > This for example, enables Pelops to perform more effective client load > balancing by ensuring that new operations are performed against the node to > which it currently has the least outstanding operations running. Because of > this architectural choice, it will even be possible to offer strategies in > the future where for example nodes are actually queried to determine their > load." > > > TIA > > > -- > > - Carlo - >
