r.connect() hangs indefinetly about rethinkdb-rs HOT 14 CLOSED

Can you rerun with the RUST_LOG environment variable set to reql,r2d2? That what do you see in the logs?

from rethinkdb-rs.

Huh, I just reran the code with the env variables set. Now it works if the server is there. Guess some update on my system fixed it or something...

However I get this when the server is not there when trying to connect. This after trying to handle the unwrap on the r.connect() call.

Connecting...

thread 'r2d2-worker-2' has overflowed its stack
fatal runtime error: stack overflow
fish: “env RUST_LOG=reql,r2d2 cargo run” terminated by signal SIGABRT (Abort)

from rethinkdb-rs.

However I get this when the server is not there when trying to connect. This after trying to handle the unwrap on the r.connect() call.

In that case, I'm closing this issue in favour of sfackler/r2d2#55. Thank you.

from rethinkdb-rs.

I think this should be reopened, seems it is when trying to send a password in the Config that it hangs.

Tried changing the RUST_LOG env to reql,r2d2, It said nothing.

let mut conf = Config::default();
let r = Client::new();
// Create a connection pool
println!("Connecting");
let conn = r.connect(conf).unwrap();
// Never get here

Tried compiling with the latest nightly, stable and --release mode. Still hangs with no output

Edit: Just wanted to say thanks for making it possible to use rethinkdb in rust, the implementation is great!

from rethinkdb-rs.

I tried some basic printf debugging, since i could not get the RUST_LOG to show any output.

Only thing i noticed is that it never advances past the Connection::maintain() , it never gets any response, not even an unexpected response or a None response, since i tried changing the mod.rs:236 to a match and put prints on those locations.

I am having a bit of trouble following the code, I am quite new to Rust in general any pointers would be greatly appreciated.

from rethinkdb-rs.

I think this should be reopened

I agree. I've been meaning to reopen this issue anyway since the other issue is closed.

from rethinkdb-rs.

I think this should be reopened, seems it is when trying to send a password in the Config that it hangs.

Did you have a RethinkDB server running?

from rethinkdb-rs.

Yeah, I noticed i get an error because of the unwrap when the server is not running, so that probably means i can handle it now, which is nice. I am running a local test instance of rethinkdb with the user bob with password secret. The connection crashes on unwrap when I supply invalid credentials, but with valid credentials I get nowhere.

from rethinkdb-rs.

I've never tried to use the driver with a username or password different from the defaults. I always run the server behind a VPN. Having said that, I don't see any reason why it shouldn't work. I can't reproduce this behaviour with your code (Rust 2018) above.

use reql::{Config, Client};

fn main() {
    let conf = Config::default();
    let r = Client::new();
    println!("Connecting");
    let _conn = r.connect(conf).unwrap();
    println!("Connected");
}

Prints the following:

~> cargo run
   Compiling reqltest v0.1.0 (/tmp/reqltest)
    Finished dev [unoptimized + debuginfo] target(s) in 2.55s
     Running `target/debug/reqltest`
Connecting
Connected

from rethinkdb-rs.

from rethinkdb-rs.

If i run a test-server locally on my laptop and insert a user via the web interface called bob and assign a password according to Rethinkdb site

If i then run my code like this:

extern crate reql;
use reql::{Config, Client};

fn main() {
    let mut conf = Config::default();
    conf.user = "bob";
    conf.password = "secret";

    let r = Client::new();
    println!("Connecting");
    let _conn = r.connect(conf).unwrap();
    println!("Connected");
}

I get

    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
     Running `target/debug/bug`
Connecting
^C⏎  

Where i have to manually abort with ctrl+c. Since it seems to get stuck in some loop of some kind.

If I supply the wrong password for bob however, then i get:

    Finished dev [unoptimized + debuginfo] target(s) in 1.91s
     Running `target/debug/bug`
Connecting
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Driver(R2D2(Error(Some("driver"))))', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Which is as expected

from rethinkdb-rs.

I checked some in the handshake code, apparently there is 3 connection requests being made at the same time, I see 3 auth requests and then 3 responses. All with differents values. The final responses then arrives a bit sporadically, but they all succeed.

Then I think the conn.maintain() loop kicks in and does something, because i am then seing connection attempts with regular intervals, which i guess are from that loop. . I am a bit unsure what the purpose of that part is though.

from rethinkdb-rs.

Ok, I figured out the error.

This driver do not support other users than admin, for the simple reason that Connection::maintain() tries to read the "server_status" table found in rethinkdb system table.

From their FAQ on system tables

Note: As of version 2.3, only the admin user can access system tables. Read Permissions and user accounts for more details on user accounts and permissions.

Which means i cannot grant another user read access on rethinkdb database, upon which this driver is dependent.

Am i correct in assuming that the Maintain command is only used to update the connection pool, I am a bit tempted to cut the parts with the connection pool and create a driver that only sends and receives querys based on a connection. Then maybe build r2d2 pool management on top of that crate.

Maybe that would make it more like the other r2d2 database drivers that exists. What do you think @rushmorem

Edit: example code that adds user bob and then tries to connect.

extern crate reql;
extern crate reql_types;
extern crate futures;
#[macro_use]
extern crate serde_json;

use futures::Stream;
use reql_types::*;
use reql::{Config, Client, Run};

fn main() -> reql::Result<()> {
    // Create a new ReQL client
    let r = Client::new();

    let conf = Config::default();
    // Create a connection pool
    println!("Connecting with default settings...");

    let conn = r.connect(conf)?;
    println!("Admin connected");

    let usr = json!({
            "id": "bob",
            "password": "secret"
            });

    println!("Inserting user bob in database");
    // Run the query
    let stati = r.db("rethinkdb")
        .table("users")
        .insert(usr)
        .run::<WriteStatus>(conn)?;

    // Process the results
    match stati.wait().next().unwrap() {
        // The server returned the response we were expecting
        Ok(status) => {
            println!("{:?}", status);
        },
        Err(status) => {
            println!("{:?}", status);
        },
    }

    let r = Client::new();

    let mut conf = Config::default();
    conf.user = "bob";
    conf.password = "secret";

    println!("trying to connect with user bob");

    let _conn = r.connect(conf)?;

    println!("Bob connected, but never gets here");
    Ok(())
}

This prints:

Connecting with default settings...
Inserting user bob in database
Some(Expected(WriteStatus { inserted: 1, replaced: 0, unchanged: 0, skipped: 0, deleted: 0, errors: 0, first_error: None, generated_keys: None, warnings: None, changes: None }))
trying to connect with user bob

from rethinkdb-rs.

I see. Thanks for looking into this. I agree that we should just drop Connection::maintain altogether and pull out r2d2 integration into a separate crate. I will be a little sad to see it Connection::maintain go because it provides one of the most novel features of this driver but in light of the complexity it adds, I think dropping it is a better idea.

Connection::maintain's job is to make sure that as long as there are database servers up, be they in the same data centre from which the initial connection was made or not, and it makes sure that the driver will always connect to the server with the lowest latency. It listens to server_status to update the pool in real time if there are any changes in any of the servers. In the process, it also pulls any additional servers that are in the cluster or that join the cluster after the pool is built.

from rethinkdb-rs.