Git Product home page Git Product logo

cql-proxy's Introduction

cql-proxy

GitHub Action Go Report Card

Table of Contents

What is cql-proxy?

cql-proxy

cql-proxy is designed to forward your application's CQL traffic to an appropriate database service. It listens on a local address and securely forwards that traffic.

When to use cql-proxy

The cql-proxy sidecar enables unsupported CQL drivers to work with DataStax Astra. These drivers include both legacy DataStax drivers and community-maintained CQL drivers, such as the gocql driver and the rust-driver.

cql-proxy also enables applications that are currently using Apache Cassandra or DataStax Enterprise (DSE) to use Astra without requiring any code changes. Your application just needs to be configured to use the proxy.

If you're building a new application using DataStax drivers, cql-proxy is not required, as the drivers can communicate directly with Astra. DataStax drivers have excellent support for Astra out-of-the-box, and are well-documented in the driver-guide guide.

Configuration

Use the -h or --help flag to display a listing all flags and their corresponding descriptions and environment variables (shown below as items starting with $):

$ ./cql-proxy -h
Usage: cql-proxy

Flags:
  -h, --help                                              Show context-sensitive help.
  -b, --astra-bundle=STRING                               Path to secure connect bundle for an Astra database. Requires '--username' and '--password'. Ignored if using the
                                                          token or contact points option ($ASTRA_BUNDLE).
  -t, --astra-token=STRING                                Token used to authenticate to an Astra database. Requires '--astra-database-id'. Ignored if using the bundle path
                                                          or contact points option ($ASTRA_TOKEN).
  -i, --astra-database-id=STRING                          Database ID of the Astra database. Requires '--astra-token' ($ASTRA_DATABASE_ID)
      --astra-api-url="https://api.astra.datastax.com"    URL for the Astra API ($ASTRA_API_URL)
      --astra-timeout=10s                                 Timeout for contacting Astra when retrieving the bundle and metadata ($ASTRA_TIMEOUT)
  -c, --contact-points=CONTACT-POINTS,...                 Contact points for cluster. Ignored if using the bundle path or token option ($CONTACT_POINTS).
  -u, --username=STRING                                   Username to use for authentication ($USERNAME)
  -p, --password=STRING                                   Password to use for authentication ($PASSWORD)
  -r, --port=9042                                         Default port to use when connecting to cluster ($PORT)
  -n, --protocol-version="v4"                             Initial protocol version to use when connecting to the backend cluster (default: v4, options: v3, v4, v5, DSEv1,
                                                          DSEv2) ($PROTOCOL_VERSION)
  -m, --max-protocol-version="v4"                         Max protocol version supported by the backend cluster (default: v4, options: v3, v4, v5, DSEv1, DSEv2)
                                                          ($MAX_PROTOCOL_VERSION)
  -a, --bind=":9042"                                      Address to use to bind server ($BIND)
  -f, --config=CONFIG                                     YAML configuration file ($CONFIG_FILE)
      --debug                                             Show debug logging ($DEBUG)
      --health-check                                      Enable liveness and readiness checks ($HEALTH_CHECK)
      --http-bind=":8000"                                 Address to use to bind HTTP server used for health checks ($HTTP_BIND)
      --heartbeat-interval=30s                            Interval between performing heartbeats to the cluster ($HEARTBEAT_INTERVAL)
      --idle-timeout=60s                                  Duration between successful heartbeats before a connection to the cluster is considered unresponsive and closed
                                                          ($IDLE_TIMEOUT)
      --readiness-timeout=30s                             Duration the proxy is unable to connect to the backend cluster before it is considered not ready
                                                          ($READINESS_TIMEOUT)
      --idempotent-graph                                  If true it will treat all graph queries as idempotent by default and retry them automatically. It may be
                                                          dangerous to retry some graph queries -- use with caution ($IDEMPOTENT_GRAPH).
      --num-conns=1                                       Number of connection to create to each node of the backend cluster ($NUM_CONNS)
      --proxy-cert-file=STRING                            Path to a PEM encoded certificate file with its intermediate certificate chain. This is used to encrypt traffic
                                                          for proxy clients ($PROXY_CERT_FILE)
      --proxy-key-file=STRING                             Path to a PEM encoded private key file. This is used to encrypt traffic for proxy clients ($PROXY_KEY_FILE)
      --rpc-address=STRING                                Address to advertise in the 'system.local' table for 'rpc_address'. It must be set if configuring peer proxies
                                                          ($RPC_ADDRESS)
      --data-center=STRING                                Data center to use in system tables ($DATA_CENTER)
      --tokens=TOKENS,...                                 Tokens to use in the system tables. It's not recommended ($TOKENS)

To pass configuration to cql-proxy, either command-line flags, environment variables, or a configuration file can be used. Using the docker method as an example, the following samples show how the token and database ID are defined with each method.

Using flags

docker run -p 9042:9042 \
  --rm datastax/cql-proxy:v0.1.5 \
  --astra-token <astra-token> --astra-database-id <astra-datbase-id>

Using environment variables

docker run -p 9042:9042  \
  --rm datastax/cql-proxy:v0.1.5 \
  -e ASTRA_TOKEN=<astra-token> -e ASTRA_DATABASE_ID=<astra-datbase-id>

Using a configuration file

Proxy settings can also be passed using a configuration file with the --config /path/to/proxy.yaml flag. This can be mixed and matched with command-line flags and environment variables. Here are some example configuration files:

contact-points:
  - 127.0.0.1
username: cassandra
password: cassandra
port: 9042
bind: 127.0.0.1:9042
# ...

or with a Astra token:

astra-token: <astra-token>
astra-database-id: <astra-database-id>
bind: 127.0.0.1:9042
# ...

All configuration keys match their command-line flag counterpart, e.g. --astra-bundle is astra-bundle:, --contact-points is contact-points: etc.

Setting up peer proxies

Multi-region failover with DC-aware load balancing policy is the most useful case for a multiple proxy setup.

When configuring peers: it is required to set --rpc-address (or rpc-address: in the yaml) for each proxy and it must match is corresponding peers: entry. Also, peers: is only available in the configuration file and cannot be set using a command-line flag.

Multi-region setup

Here's an example of configuring multi-region failover with two proxies. A proxy is started for each region of the cluster connecting to it using that region's bundle. They all share a common configuration file that contains the full list of proxies.

Note: Only bundles are supported for multi-region setups.

cql-proxy --astra-bundle astra-region1-bundle.zip --username token --password <astra-token> \
  --bind 127.0.0.1:9042 --rpc-address 127.0.0.1 --data-center dc-1 --config proxy.yaml
cql-proxy ---astra-bundle astra-region2-bundle.zip --username token --password <astra-token> \
  --bind 127.0.0.2:9042 --rpc-address 127.0.0.2 --data-center dc-2 --config proxy.yaml

The peers settings are configured using a yaml file. It's a good idea to explicitly provide the --data-center flag, otherwise; these values are pulled from the backend cluster and would need to be pulled from the system.local and system.peers table to properly setup the peers data-center: values. Here's an example proxy.yaml:

peers:
  - rpc-address: 127.0.0.1
    data-center: dc-1
  - rpc-address: 127.0.0.2
    data-center: dc-2

Note: It's okay for the peers: to contain entries for the current proxy itself because they'll just be omitted.

Getting started

There are three methods for using cql-proxy:

  • Locally build and run cql-proxy
  • Run a docker image that has cql-proxy installed
  • Use a Kubernetes container to run cql-proxy

Locally build and run

  1. Build cql-proxy.

    go build
  2. Run with your desired database.

    • DataStax Astra cluster:

      ./cql-proxy --astra-token <astra-token> --astra-database-id <astra-database-id>

      The <astra-token> can be generated using these instructions. The proxy also supports using the Astra Secure Connect Bundle along with a client ID and secret generated using these instructions:

      ./cql-proxy --astra-bundle <your-secure-connect-zip> \
      --username <astra-client-id> --password <astra-client-secret>
      
    • Apache Cassandra cluster:

      ./cql-proxy --contact-points <cluster node IPs or DNS names> [--username <username>] [--password <password>]

Run a cql-proxy docker image

  1. Run with your desired database.

    • DataStax Astra cluster:

      docker run -p 9042:9042 \
        datastax/cql-proxy:v0.1.5 \
        --astra-token <astra-token> --astra-database-id <astra-database-id>

      The <astra-token> can be generated using these instructions. The proxy also supports using the Astra Secure Connect Bundle, but it requires mounting the bundle to a volume in the container:

      docker run -v <your-secure-connect-bundle.zip>:/tmp/scb.zip -p 9042:9042 \
      --rm datastax/cql-proxy:v0.1.5 \
      --astra-bundle /tmp/scb.zip --username <astra-client-id> --password <astra-client-secret>
    • Apache Cassandra cluster:

      docker run -p 9042:9042 \
        datastax/cql-proxy:v0.1.5 \
        --contact-points <cluster node IPs or DNS names> [--username <username>] [--password <password>]

If you wish to have the docker image removed after you are done with it, add --rm before the image name datastax/cql-proxy:v0.1.5.

Use Kubernetes

Using Kubernetes with cql-proxy requires a number of steps:

  1. Generate a token following the Astra instructions. This step will display your Client ID, Client Secret, and Token; make sure you download the information for the next steps. Store the secure bundle in /tmp/scb.zip to match the example below.

  2. Create cql-proxy.yaml. You'll need to add three sets of information: arguments, volume mounts, and volumes. A full example can be found here.

  • Argument: Modify the local bundle location, username and password, using the client ID and client secret obtained in the last step to the container argument.

    command: ["./cql-proxy"]
    args: ["--astra-bundle=/tmp/scb.zip","--username=Client ID","--password=Client Secret"]
    
  • Volume mounts: Modify /tmp/ as a volume mount as required.

    volumeMounts:
      - name: my-cm-vol
      mountPath: /tmp/
    
  • Volume: Modify the configMap filename as required. In this example, it is named cql-proxy-configmap. Use the same name for the volumes that you used for the volumeMounts.

    volumes:
      - name: my-cm-vol
        configMap:
          name: cql-proxy-configmap        
    
  1. Create a configmap. Use the same secure bundle that was specified in the cql-proxy.yaml.

    kubectl create configmap cql-proxy-configmap --from-file /tmp/scb.zip 
  2. Check the configmap that was created.

    kubectl describe configmap cql-proxy-configmap
      
      Name:         cql-proxy-configmap
      Namespace:    default
      Labels:       <none>
      Annotations:  <none>
    
      Data
      ====
    
      BinaryData
      ====
      scb.zip: 12311 bytes
  3. Create a Kubernetes deployment with the YAML file you created:

    kubectl create -f cql-proxy.yaml
  4. Check the logs:

    kubectl logs <deployment-name>

Known issues

Token-aware load balancing

Drivers that use token-aware load balancing may print a warning or may not work when using cql-proxy. Because cql-proxy abstracts the backend cluster as a single endpoint this doesn't always work well with token-aware drivers that expect there to be at least "replication factor" number of nodes in the cluster. Many drivers print a warning (which can be ignored) and fallback to something like round-robin, but other drivers might fail with an error. For the drivers that fail with an error it is required that they disable token-aware or configure the round-robin load balancing policy.

cql-proxy's People

Contributors

absurdfarce avatar bogdanprodanj avatar david-joy-ds avatar dougwettlaufer avatar hemidactylus avatar mpenick avatar polandll avatar wizardishungry avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cql-proxy's Issues

Automatically upgrade the consistency level for write queries when connected to Astra

Astra implements guardrails that don't allow writes at the following consistency levels (CL): ANY, ONE, LOCAL_ONE. For DataStax drivers when using the secure connect bundle the minimum CL is set to LOCAL_QUORUM. Perhaps the driver could automatically upgrade unsupported consistencies for write queries to LOCAL_QUORUM to match this behavior.

Move to Go 1.18

I think is safe to move to Go 1.18 and remove Go 1.16 and 1.15 from CI. This will allow for simplification of a couple places in the code and remove uses of ioutil, etc.

Improve warning when initial connection is to host with rpc_address of 0.0.0.0

This case leads to the following error message:

{"level":"error","ts":1674158444.9508557,"caller":"proxycore/cluster.go:357","msg":"unable to create new endpoint","error":"ignoring host because its `peer` is not set or is invalid","stacktrace":
"github.com/datastax/cql-proxy/proxycore.(*Cluster).addHosts\n\t/go/src/cql-proxy/proxycore/cluster.go:357
github.com/datastax/cql-proxy/proxycore.(*Cluster).queryHosts\n\t/go/src/cql-proxy/proxycore/cluster.go:300
github.com/datastax/cql-proxy/proxycore.(*Cluster).connect\n\t/go/src/cql-proxy/proxycore/cluster.go:223
github.com/datatax/cql-proxy/proxycore.ConnectCluster\n\t/go/src/cql-proxy/proxycore/cluster.go:163
github.com/datastax/cql-proxy/proxy.(*Proxy).Connect\n\t/go/src/cql-proxy/proxy/proxy.go:167
github.com/datastax/cql-proxy/proxy.(*runConfig).listenAndServe\n\t/go/src/cql-proxy/proxy/run.go:274
github.com/datastax/cql-proxy/proxy.Run\n\t/go/src/cql-proxy/proxy/run.go:195
main.main\n\t/go/src/cql-proxy/proxy.go:29
runtime.main\n\t/usr/local/go/src/runtime/proc.go:225"}                                                                          
panic: runtime error: index out of range [0] with length 0

Relevant code is NewEndpoint. This code starts with "rpc_address" and falls back to "peer" if that's set to 0.0.0.0. This doesn't work for system.local, though, where "peer" is not a defined column. Thus we wind up with the error message above which doesn't really communicate what's going on.

It would be nice if we could provide a more informative error to the user, at least something indicating that 0.0.0.0 rpc_addresses will introduce this behaviour.

Performance issues under load

The cql-proxy sidecar is having trouble handling larger loads. We brought it up to our staging environment which has consistent loads at about an average of at about .25 million reads per hour and we noticed that our requests started timing out.

DB Retry for Get object has finally succeeded with 1 retries. No error on the query.
DB Retry last error: gocql: no response received from cassandra within timeout period
DB Retry for Objects exceeded retry count of 10.
DB Retry last error: gocql: no response received from cassandra within timeout period

Properly handle DDL queries and update schema version

When not using Astra, DDL queries should wait at the proxy until the schema version is consistent across all nodes in the cluster. Also, it'd be nice if the schema version in the mock system tables matched the actual schema version. Maybe it's not important...

Connection Closed: Unable to decode header

When try to make connection with proxy service. It logs a message that "unable to decode hearder" and close the connection. Need to fix is soon. Please find the attach error's screenshot.
astra_connection_error

When we try to run it with --debug.
image

@mpenick

Quantify performance impact of the proxy

Run performance tests to quantify the impact of the proxy versus connecting directly to a cluster. Also, quantify the saturation point in terms of throughput and number of connections. Essentially, determine ballpark numbers to help guide users decisions on how to use and deploy the proxy.

Improve README.md

Add better information for building, using the docker side, and general usage.

Handle mixed protocol versions e.g. client = V5, server = V4

The protocol version supported by the proxy shouldn't have to match the protocol version of the cluster. This could enable legacy applications. It could be fairly expensive to re-encode queries, so using the same protocol version should be preferred.

Convert `system` schema tables to/from `system_schema` tables

Older versions of driver use to use schema tables that lived under system, but newer versions of Cassandra and DSE have removed those tables in favor of tables under system_schema. The proxy would have to intercept these queries and convert them to the new tables.

To make the connection process work for older driver that use schema tables under system the proxy currently return empty tables. In the future we could intercept these and return actual values if needed.

"describe" command doesnt display results

describe keyspaces and describe tables both return blank when I run it in cqlsh.

Connected to cql-proxy at 127.0.0.1:9042 [cqlsh 6.0.0 | Cassandra 4.0.0.6816 | CQL spec 3.4.5 | Native protocol v4]
Screen Shot 2021-12-20 at 11 00 37 AM

I am able to retrieve results on the Astra UI using cql-proxy as well as just using the secure connect bundle, but not when I connect with the proxy.

Use the prepare cache to prepare on node add/up events

When adding a new node or restarting node its prepared cache is empty. This causes execution of prepare queries to fail with unprepared errors. We handle this at the proxy-level by handling unprepared errors with preparing the queries on the executing connection and re-executing the original request. This results in extra latency and it can cause a "stampeding herd" of preparing on the new node. To mitigate these issues we can prepare new and newly restarted nodes with the queries that are in the proxy's prepared cache before marking the node as available.

Investigate repreparing errors

INFO client-0 - STDOUT: 20:15:49.108 [cluster1-nio-worker-10] INFO c.d.driver.core.RequestHandler - Query 'SELECT * from testdb_2c5ad08f.soil_meta WHERE row_key=? AND period1=? AND period0=? AND time_range=? AND level1=? AND level0=? AND level_type=? AND parameter=? AND param_table_ver=?;' on keyspace 'null' is not prepared on localhost/127.0.0.1:9042, preparing before retrying executing. Seeing this message a few times is fine, but seeing it a lot may be source of performance problems

It seems like there's some interaction with the cql-proxy that's causing excessive reprepares. This needs to be reproduced and fixed.

Abstract SCB handling into standalone lib

Consider pulling Astra SCB logic in cql-proxy into a free-standing library. This library could be managed and versioned separately from cql-proxy proper and could provide an API for the following functions:

  • SCB creation from various inputs (URLs, paths, possibly the raw materials that make up an SCB, etc.)
  • SCB interrogation
  • SCB comparison

Doing so would give us a single place for this logic to live; customers can then use it in whatever way suits them.

It would also allow us to decouple gocql-astra from cql-proxy. At the moment gocql-astra imports the SCB handling fns from cql-proxy to deal with SCBs. Importing the (much smaller) lib being discussed here would provide a clearer picture of the actual dependencies and avoid the weird condition of gocql-astra depending upon the whole of cql-proxy (when it really doesn't).

Add health and liveness check

Add (optional) health and liveness checks using an embedded http endpoint. Maybe it should query a system table? This is useful for k8s deploys to see if the service is ready to take traffic and is still running properly.

Metrics

Would love to see metrics for database at the proxy that could be exposed as a prom exporter.

Equivalent metrics to what the java driver provides would be perfect.

URGENT: Multiple Requests Handle Issue

Hello @mpenick

Currently I'm facing another issue. This is related to timeout. Let me paste the error message here:

Query (SELECT * FROM table_name WHERE id=?;) failed com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: host:9042 (com.datastax.driver.core.exceptions.DriverException: Timeout while trying to acquire available connection (you may want to increase the driver number of per-host connections)))

I've event increase the per host connections. Let share that part of code with you here:

private val cluster = Cluster.builder() .addContactPoints(configuration.astraHostnames: _*) .withPort(9042) .withPoolingOptions(new PoolingOptions().setConnectionsPerHost(HostDistance.LOCAL, 40, 10000).setConnectionsPerHost(HostDistance.REMOTE, 20, 5000)) .withSocketOptions(new SocketOptions().setReadTimeoutMillis(configuration.cassandraReadTimeout)) .withLoadBalancingPolicy(LatencyAwarePolicy.builder(new TokenAwarePolicy(new RoundRobinPolicy())).build) .withRetryPolicy(DefaultRetryPolicy.INSTANCE) .withSpeculativeExecutionPolicy(new ConstantSpeculativeExecutionPolicy(500, 2)) .build()

I think driver is working properly which is v.2.1.10.3. But my cql-proxy service is unable to handle multiple requests in hundreds at the same time.
Could you please share that how many request cql-proxy can handle at a time? and how I can change that number?

Problems with AWS Keyspaces

Hello,

I have a PHP third-party application, which needs to access a Cassandra keyspace and it does not support TLS connections; I have set up a Cassandra keyspace in AWS Keyspaces, which requires TLS connections: therefore I am trying to use this proxy.

After that I have followed these instructions, I managed successfully to connect to my Cassandra keyspace on AWS Keyspaces locally via cqlsh.

Before configuring your proxy in a Kubernetes container (where the PHP third-party application is running), I am trying to run the cql-proxy image for some local tests:

docker run -p 9042:9042 \
  --rm datastax/cql-proxy:v0.1.3 \
  --contact-points="cassandra.eu-west-1.amazonaws.com" --username="${CASSANDRA_USERNAME}" \
  --password="${CASSANDRA_PASSWORD}" --port="9142" --bind="127.0.0.1:9042" \
  --proxy-cert-file="/path/to/sf-class2-root.crt" --debug

Unfortunately this simply returns the following error without further explanation:

cql-proxy: error: unable to connect to cluster context deadline exceeded

Am I missing something in the parameters passed for my test? Has somebody else tested this proxy solution with AWS Keyspaces already? Thanks in advance.

Add heartbeats to client connections

The proxy opens long lived connections and some network device will kill idle connections. Add a background task that sends a CQL protocol OPTIONS request. Also, make sure TCP nodelay is enabled and TCP keepalive's are disabled on client connections (connections to from the proxy to the cluster).

Automatically retry queries when they're idempotent

The proxy appears as a single node cluster to drivers. If a query fails because of an intermittent failure the driver will not be able to retry on another node because from its view there is only a single node. The proxy has a full view of the backing cluster and can automatically retry when the query is determined to be idempotent.

This also has the potential to enable automatic multi-region fail over.

Add support for batches

The proxy doesn't currently support batches.

  • Parser needs to look for "BATCH" queries to determine idempotency. T
  • The batch request needs to be inspected for query idempotency. One non-idempotent query then the whole batch is non-idempotent.

Token ring issue

Context: Trying to use Astra DB as the backend for Temporal OSS for community users to use with ease. Temporal offers two ways to install their server: helm charts and docker compose. We were successful with helm charts as we unzipped the scb file and did it manually. However, tried cql-proxy with both docker compose and helm charts and ran in the following issue.

Overview: Trying to use cql-proxy to connect with Temporal OSS services. Connection with cql-proxy itself is up and listening as given by listening message:

{"level":"info","ts":1646853171.9829385,"caller":"proxy/proxy.go:194","msg":"proxy is listening","address":"[::]:9042"}

Runs into the follow error and panics.

Error message:

...
temporal                | + echo 'Waiting for Temporal server to start...'
temporal                | Waiting for Temporal server to start...
temporal                | + sleep 1
temporal                | + tctl cluster health
temporal                | + grep SERVING
temporal                | panic: token map different size to token ring: got 0 expected 1
...

Need to figure out this token ring policy issue so that it does not panic and continues instead.

How to reproduce issue:
Quick install and run Temporal server.

Use this config file:
docker-compose-cqlproxy.txt
(uploaded as txt > convert to yaml file)

Use this command:
docker-compose -f docker-compose-cqlproxy.yaml up

Optimize parsing

The proxy is currently using a full antlr4 parser which has yet to be benchmarked, but looks to produce less than optimal code. At the least, it creates unnecessary garbage (memory) when little to no memory allocation is required for the tasks required by the parser:

  1. To intercept system.local/system.peer and USE <keyspace> queries
  2. Determine if a query is idempotent

It's possible that these narrower in scope tasks could benefit from a hand optimized recursive decent parser. Also, we should benchmark antlr's tokenizer versus others (e.g. ragel).

Also, determining idempoentcy, could be possibly be delayed until the statement fails and needs to be retried. Successfully executing statement do not require knowing whether they're idempotent.

cql-proxy 0.1.4 runtime issue

๐Ÿ‘‹ trying to build the latest release, but run into some build issue. The error log is as below:

build issue
  ==> /opt/homebrew/Cellar/cql-proxy/0.1.4/bin/cql-proxy -b secure.txt --bind 127.0.0.1 2>&1
  cql-proxy: error: unable to open bundle secure.txt from file: zip: not a valid zip file
  panic: runtime error: invalid memory address or nil pointer dereference
  [signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x104b35594]

  goroutine 1 [running]:
  github.com/datastax/cql-proxy/proxycore.ConnectCluster({0x104d7e158?, 0x140001683c0}, {0x4, {0x0, 0x0}, {0x0, 0x0}, {0x104d7cd58, 0x140000c14a0}, 0x0, ...})
  	github.com/datastax/cql-proxy/proxycore/cluster.go:153 +0x2f4
  github.com/datastax/cql-proxy/proxy.(*Proxy).Connect(0x140002a8000)
  	github.com/datastax/cql-proxy/proxy/proxy.go:167 +0x23c
  github.com/datastax/cql-proxy/proxy.(*runConfig).listenAndServe(0x140000a4000, 0x140002a8000, 0x14000284300, {0x104d7e158?, 0x140001683c0}, 0x140000b8960)
  	github.com/datastax/cql-proxy/proxy/run.go:274 +0x11c
  github.com/datastax/cql-proxy/proxy.Run({0x104d7e158, 0x140001683c0}, {0x1400010e060, 0x4, 0x4})
  	github.com/datastax/cql-proxy/proxy/run.go:195 +0xb58
  main.main()
  	github.com/datastax/cql-proxy/proxy.go:29 +0xc0
  Error: cql-proxy: failed
  An exception occurred within a child process:
    Minitest::Assertion: Expected: 1
    Actual: 2

full build log, https://github.com/Homebrew/homebrew-core/actions/runs/3991512785/jobs/6846471831
relates to Homebrew/homebrew-core#121363

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.