connection error

[திருச்சிராப்பள்ளி]

>>> from cassandra.cqlengine import columns

works

>>> from cassandra.cqlengine import connection

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "/root/Downloads/python-driver-master/cassandra/cqlengine/connection.py", line 20, in <module>

    from cassandra.cluster import Cluster, _NOT_SET, NoHostAvailable, UserTypeDoesNotExist

  File "/root/Downloads/python-driver-master/cassandra/cluster.py", line 23, in <module>

    from concurrent.futures import ThreadPoolExecutor

  File "/usr/local/lib/python3.4/site-packages/futures-3.0.2-py3.4.egg/concurrent/futures/__init__.py", line 8, in <module>

    from concurrent.futures._base import (FIRST_COMPLETED,

  File "/usr/local/lib/python3.4/site-packages/futures-3.0.2-py3.4.egg/concurrent/futures/_base.py", line 355

    raise type(self._exception), self._exception, self._traceback

                               ^

SyntaxError: invalid syntax

please help us to solve 

Thanks

[Trichy Cassandra Group]

we use 

python 3.4

cassandra-driver==2.5.1

[Kishan Karunaratne]

I cannot reproduce this using Python 3.4.0 and driver v. 2.5.1. What platform are you running on?

Kishan Karunaratne

Test Engineer

To unsubscribe from this group and stop receiving emails from it, send an email to python-driver-u...@lists.datastax.com.

[திருச்சிராப்பள்ளி மாவட்டம்]

cassandra 2.0.14 

CentOS 6

[Adam Holmberg]

It looks like the latest futures module is using a 'raise' grammar not supported in Python 3.4.1:

https://www.python.org/dev/peps/pep-3109/#id14

Introduced here:

https://github.com/agronholm/pythonfutures/commit/86ebe126e6c9a3b652feb7fe79a4a10fd5272127

Adam

To unsubscribe from this group and stop receiving emails from it, send an email to python-driver-u...@lists.datastax.com.

[Trichy Cassandra Group]

python 3.4

cassandra-driver==2.5.1

cassandra 2.0.14 

on CentOS 6

[Adam Holmberg]

I think your best recourse is to downgrade to futures=2.2.0 and file an issue with pythonfutures:

https://github.com/agronholm/pythonfutures/issues

To unsubscribe from this group and stop receiving emails from it, send an email to python-driver-u...@lists.datastax.com.

[திருச்சிராப்பள்ளி மாவட்டம்]

 futures=2.2.0

python 3.4

cassandra-driver==2.5.1

cassandra 2.0.14 

on CentOS 6

works... thanking you for your great supports 

[திருச்சிராப்பள்ளி மாவட்டம்]

[root]# cqlsh

Connected to Test Cluster at localhost:9160.

[cqlsh 4.1.1 | Cassandra 2.0.14 | CQL spec 3.1.1 | Thrift protocol 19.39.0]

Use HELP for help.

cqlsh> use kk;

cqlsh:kk> exit

[root]# python3

Python 3.4.2 (default, May 12 2015, 05:54:38)

[GCC 4.4.7 20120313 (Red Hat 4.4.7-11)] on linux

Type "help", "copyright", "credits" or "license" for more information.

>>> from cassandra.cluster import Cluster

>>> cluster = Cluster(['127.0.0.1'])

>>> session = cluster.connect('kk')

The connection seems to hang ( attach screenshot)

thanks

[திருச்சிராப்பள்ளி மாவட்டம்]

[root]# cqlsh

Connected to Test Cluster at localhost:9160.

[cqlsh 4.1.1 | Cassandra 2.0.14 | CQL spec 3.1.1 | Thrift protocol 19.39.0]

Use HELP for help.

cqlsh> use kk;

cqlsh:kk> exit

[root]# python3

Python 3.4.2 (default, May 12 2015, 05:54:38)

[GCC 4.4.7 20120313 (Red Hat 4.4.7-11)] on linux

Type "help", "copyright", "credits" or "license" for more information.

>>> from cassandra.cluster import Cluster

>>> cluster = Cluster(['127.0.0.1'])

>>> session = cluster.connect('kk')

The connection seems to hang ( attach screenshot)

thanks

[Adam Holmberg]

There's not a lot to go on here. I would note that, in Cassandra 2.0, cqlsh uses a different client API than the driver (thrift on 9160, vs native on 9042). Are you able to connect to 127.0.0.1:9042?

nc -nzv 127.0.0.1 9042

You might also try debug logging to help troubleshoot where things are hanging up:

import logging

logging.basicConfig(level=logging.DEBUG)

...

Adam Holmberg

[திருச்சிராப்பள்ளி மாவட்டம்]

nc -nzv 127.0.0.1 9042

Connection to 127.0.0.1 9042 port [tcp/*] succeeded!

DEBUG:cassandra.cluster:[control connection] Established new connection <AsyncoreConnection(139685171688112) 127.0.0.1:9042>, registering watchers and refreshing schema and topology

[திருச்சிராப்பள்ளி மாவட்டம்]

DEBUG:cassandra.cluster:Connecting to cluster, contact points: ['127.0.0.1']; protocol version: 2

DEBUG:cassandra.pool:Host 127.0.0.1 is now marked up

DEBUG:cassandra.cluster:[control connection] Opening new connection to 127.0.0.1

DEBUG:cassandra.connection:Not sending options message for new connection(139925125936632) to 127.0.0.1 because compression is disabled and a cql version was not specified

DEBUG:cassandra.connection:Sending StartupMessage on <AsyncoreConnection(139925125936632) 127.0.0.1:9042>

DEBUG:cassandra.connection:Sent StartupMessage on <AsyncoreConnection(139925125936632) 127.0.0.1:9042>

DEBUG:cassandra.io.asyncorereactor:Starting asyncore event loop

DEBUG:cassandra.connection:Got ReadyMessage on new connection (139925125936632) from 127.0.0.1

DEBUG:cassandra.cluster:[control connection] Established new connection <AsyncoreConnection(139925125936632) 127.0.0.1:9042>, registering watchers and refreshing schema and topology

[Adam Holmberg]

Based on 'nc' success, and the logs you've provided here, it seems that the driver is able to connect to the server and exchange messages.

Are you saying it never returns from Cluster().connect()?

Are there any warnings or errors in the Cassandra server log?

Are you setting Cluster.control_connection_timeout to something other than default?

With default settings I would at least expect an error at this phase to produce one of these logs:

https://github.com/datastax/python-driver/blob/2.5.1/cassandra/cluster.py#L1895-L1901

If this log is complete, it might indicate that it's not getting through watcher registration. If this is the case, you might troubleshoot further by debugging or putting some additional logs in Connection.wait_for_responses.

Any additional information you can provide might help troubleshooting.

Regards,

Adam

[திருச்சிராப்பள்ளி மாவட்டம்]

>> Are you saying it never returns from Cluster().connect()?

yes

>> Are there any warnings or errors in the Cassandra server log?

no (last log attached)

Are you setting Cluster.control_connection_timeout to something other than default?

no

With default settings I would at least expect an error at this phase to produce one of these logs:

https://github.com/datastax/python-driver/blob/2.5.1/cassandra/cluster.py#L1895-L1901

If this log is complete, it might indicate that it's not getting through watcher registration. If this is the case, you might troubleshoot further by debugging or putting some additional logs in Connection.wait_for_responses.

thanks