Cool, so it's a server side because
- in the client side stack the thrift code is raising the error
- server side log has this DEBUG 22:29:10,318 ... timed out
The TimedOutException is raised when the number of replicas required by your CL
have not returned inside the timespan specified by rpc_
Client side (it is just a 5th instance in the same EC2 zone, having
stress.py installed on it) gives the following error:
Process Inserter-4:
Traceback (most recent call last):
File "/usr/lib64/python2.6/multiprocessing/process.py", line 232, in
_bootstrap
self.run()
File "stress.py", line
Is this a client side time out or a server side one? What does the error stack
look like ?
Also check the server side logs for errors. The thrift API will raise a timeout
when less the CL level of nodes return in rpc_timeout.
Good luck
Aaron
On 9/03/2011, at 7:37 AM, ruslan usifov wrote:
>
2011/3/8 A J
> Trying out stress.py on AWS EC2 environment (4 Large instances. Each
> of 2-cores and 7.5GB RAM. All in the same region/zone.)
>
> python stress.py -o insert -d
> 10.253.203.224,10.220.203.48,10.220.17.84,10.124.89.81 -l 2 -e ALL -t
> 10 -n 500 -S 100 -k
>
> (I want to try wit
Trying out stress.py on AWS EC2 environment (4 Large instances. Each
of 2-cores and 7.5GB RAM. All in the same region/zone.)
python stress.py -o insert -d
10.253.203.224,10.220.203.48,10.220.17.84,10.124.89.81 -l 2 -e ALL -t
10 -n 500 -S 100 -k
(I want to try with column size of about 1MB. I
