Thread 4 (Thread 0x7f6ca5eaa700 (LWP 910)): #0 0x00007f6cacedc933 in select () from /lib64/libc.so.6 #1 0x00000000004ad6fa in tacopie::io_service::poll() () #2 0x00007f6cad77d230 in ?? () from /lib64/libstdc++.so.6 #3 0x00007f6cacbdadf3 in start_thread () from /lib64/libpthread.so.0 #4 0x00007f6cacee51ad in clone () from /lib64/libc.so.6

Threads: 2344 total, 3 running, 2341 sleeping, 0 stopped, 0 zombie %Cpu(s): 21.0 us, 32.5 sy, 0.0 ni, 46.3 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st KiB Mem: 16269700 total, 15801636 used, 468064 free, 158872 buffers KiB Swap: 0 total, 0 used, 0 free. 2272844 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
910 root 20 0 416432 1336 980 R 99.8 0.0 46:30.66 PlayBackServer

Some issues are reported concerning the network part. (#19 #21 #24 #25) One is concerning the unix version, the other are mostly concerning the windows port.

I am currently working on an external library providing networking TCP features in a much-enhanced design.

This external library is intended to replace the networking module of cpp_redis and this should fix these issues.

Hi Cylix,

Before I get to the issue, I would like to thank you for the great library and your continued support and addition of new features!

I was sad to see the dropped support for the sync client, since it was the main reason I started using the library, but I've managed to make it work with a copy of the old code and some additions of sync_commit to the commands, but this isn't the problem. I had to update the library because we needed Sentinel support and your update was as if timed with our new requirement :D.

With the previous and new version I've tried to establish a redis connection after a fork, but it doesn't seem to work if there was a previous redis connection (even if terminated). For simplicity's sake and to get an idea of what I'm doing, this is the code I'm testing (the final version of it, because I've tried other things as well, which don't seem to work either), but since it uses the sync client you won't be able to compile it:

	cpp_redis::sync_client* redis = new cpp_redis::sync_client();

	redis->connect("127.0.0.1", 6379);
	redis->select(0);

	cout << redis->is_connected() << " get " << redis->get("test") << endl;
	redis->disconnect(true);

	delete redis;

	pid_t pid = fork();

	redis = new cpp_redis::sync_client();

	cout << pid << endl;

	cout << pid << " is_connected " << redis->is_connected() << endl;
	//cout << pid << " " << redis.get("test") << endl;

	//cout << pid << " disconnect" << endl;
	//redis.disconnect();
	cout << pid << " connect" << endl;
	redis->connect("127.0.0.1", 6379);
	cout << pid << " is_connected " << redis->is_connected() << endl;
	cout << pid << " select" << endl;
	redis->select(0);
	cout << pid << " after select" << endl;

	cout << pid << " is_connected " << redis->is_connected() << endl;
	cout << pid << " get " << redis->get("test") << endl;

	if (pid != 0)
		wait(pid);

The "test" key has been already pre-set in redis and I've tried lots of different configurations without pointers and disconnection and whatnot. I thought that it had to do something with destroying the instance, but it doesn't seem to work as well. The output I'm getting is: for the parent all commands are executed, but for the child the last thing printed is the " select" statement, which means that it hangs on the line redis->select(0);. Just to note, if no redis instance is present before the fork, the child is able to establish a connection, but it seems like something in the fork is bugging the library (reconnection and destruction don't help). While for now this was sort of ok, most of the time we need the parent to be able to have a redis connection prior to the fork and it doesn't work in any of the ways I've tried.

I would be grateful if you can look into this, since fork-ing is a rather common thing to do in multiprocess applications and to be quite frank I'm surprised that no one has reported this issue (which in the beginning led me to think that the problem was in my usage of the library, but I don't have many options left now :D ).

The ideal case would be to have an active redis connection in the parent and after fork-ing to reconnect only the child so that it has its own handler and the parent doesn't need to disconnect and connect again.

Best Regards, Alex

Hi,

I am heavily dependent on the redis subscriber and recently while listening to a publish from python script my redis subscriber gets disconnected and the re-connection (from the logs) seems going fine but I stop receiving any callbacks from the subscriber. I tried applying the changes from #73 but still it doesn't work. Please help.

Thanks, Siril.

Hey, Thanks for creating this project. I think its sorely needed and very well made.

I find that the Subscriber is not working on windows. I just copied your redis_subscriber.cpp example into the TEST project on windows

• loaded #pragma comment(lib,"WS2_32") and ran it.

It connects to redis makes a subscription - and shows as subscribed on redis. But the subscription callback is not called. Once in a while a single message might make it through - but never more than that. something seems to be wrong here.

Please take a look. thanks,

I'm trying to compile two days, but I always get linking errors, I'm trying to compile a module with godot (a game engine), I'm not sure where the error may be, but I've never had problems linking libraries when compiling modules on godot. The error is this:

[ 97%] Linking Program        ==> bin/godot.x11.tools.64
modules/libmodules.x11.tools.64.a(gdredis.x11.tools.64.o): In function `GDRedis::GDRedis()':
/home/noloop/godot-3.0-20out2017/modules/gdredis/gdredis.cpp:5: undefined reference to `cpp_redis::client::client()'
modules/libmodules.x11.tools.64.a(gdredis.x11.tools.64.o): In function `GDRedis::~GDRedis()':
/home/noloop/godot-3.0-20out2017/modules/gdredis/gdredis.h:17: undefined reference to `cpp_redis::client::~client()'
collect2: error: ld returned 1 exit status
scons: *** [bin/godot.x11.tools.64] Error 1
scons: building terminated because of errors.

I do not understand why it tells me this "In function `GDRedis::~GDRedis()':" being that neither destructor has in my code. I've tried everything I imagined it could be, and I have no idea what to try.

What can you tell me when you speak"undefined reference to"?

Hi Simon @Cylix, thanks for the effort you put in this project.

The tool chain of my current project requires a MS Visual C++ compiler. I added project and solution files for MS Visual Studio 2017 for the current version:

• Visual Studio version 15 (a.k.a. 2017)
• VC++ tools version 15.0
• Platform tool set v141

The project file assumes, that tacopie is checked out and compiled in directory cpp_redis/tacopie.

Are you interested in merging this into your work?

Any comments are welcome.

Before submitting the pull request, ensure that:

• [x] your feature works as expected and is tested
• [x] all tests pass on both your computer and the Travis
• [N/A] you have used the formatting tool

There is a disconnect issue in the examples that puzzles me. The sigint_handler and the subsequent disconnection handler are invoked upon sending the interrupt signal, but the main function does not terminate.

Adding a sleep(1) inside the "while (not should_exit);" loop appears to solve the termination issue, but is there possibly a disconnect/threading issue at play here?

Thank you for a nice Redis client!

Unfortunately I get always errors while compiling your samples. Could you perhaps provide an example in short shell commands for linux (tried it on Ubuntu LTS).

Regards,

Tilman

The cpp_redis build is fine in both Debug/Release mode. And I copied the cpp_redis.lib and tacopie.lib to my project folder and referred them in the project setting. I got some link errors when trying to build:

1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_accept referenced in function "public: class tacopie::tcp_socket __cdecl tacopie::tcp_socket::accept(void)" (?accept@tcp_socket@tacopie@@QEAA?AV12@XZ) 1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_bind referenced in function "public: void __cdecl tacopie::tcp_socket::bind(class std::basic_string<char,struct std::char_traits,class std::allocator > const &,unsigned int)" (?bind@tcp_socket@tacopie@@QEAAXAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@I@Z) 1>tacopie.lib(self_pipe.obj) : error LNK2001: unresolved external symbol __imp_bind 1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_closesocket referenced in function "public: void __cdecl tacopie::tcp_socket::close(void)" (?close@tcp_socket@tacopie@@QEAAXXZ) 1>tacopie.lib(self_pipe.obj) : error LNK2001: unresolved external symbol __imp_closesocket 1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_connect referenced in function "public: void __cdecl tacopie::tcp_socket::connect(class std::basic_string<char,struct std::char_traits,class std::allocator > const &,unsigned int)" (?connect@tcp_socket@tacopie@@QEAAXAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@I@Z) 1>tacopie.lib(self_pipe.obj) : error LNK2001: unresolved external symbol __imp_connect 1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_htons referenced in function "public: void __cdecl tacopie::tcp_socket::connect(class std::basic_string<char,struct std::char_traits,class std::allocator > const &,unsigned int)" (?connect@tcp_socket@tacopie@@QEAAXAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@I@Z) 1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_listen referenced in function "public: void __cdecl tacopie::tcp_socket::listen(unsigned __int64)" (?listen@tcp_socket@tacopie@@QEAAX_K@Z) 1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_recv referenced in function "public: class std::vector<char,class std::allocator > __cdecl tacopie::tcp_socket::recv(unsigned __int64)" (?recv@tcp_socket@tacopie@@QEAA?AV?$vector@DV?$allocator@D@std@@@std@@_K@Z) 1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_send referenced in function "public: unsigned __int64 __cdecl tacopie::tcp_socket::send(class std::vector<char,class std::allocator > const &,unsigned __int64)" (?send@tcp_socket@tacopie@@QEAA_KAEBV?$vector@DV?$allocator@D@std@@@std@@_K@Z) 1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_socket referenced in function "private: void __cdecl tacopie::tcp_socket::create_socket_if_necessary(void)" (?create_socket_if_necessary@tcp_socket@tacopie@@AEAAXXZ) 1>tacopie.lib(self_pipe.obj) : error LNK2001: unresolved external symbol __imp_socket 1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_getaddrinfo referenced in function "public: void __cdecl tacopie::tcp_socket::connect(class std::basic_string<char,struct std::char_traits,class std::allocator > const &,unsigned int)" (?connect@tcp_socket@tacopie@@QEAAXAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@I@Z) 1>tacopie.lib(tcp_socket.obj) : error LNK2019: unresolved external symbol __imp_freeaddrinfo referenced in function "public: void __cdecl tacopie::tcp_socket::connect(class std::basic_string<char,struct std::char_traits,class std::allocator > const &,unsigned int)" (?connect@tcp_socket@tacopie@@QEAAXAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@I@Z) 1>tacopie.lib(io_service.obj) : error LNK2019: unresolved external symbol __imp_WSAPoll referenced in function "private: void __cdecl tacopie::io_service::poll(void)" (?poll@io_service@tacopie@@AEAAXXZ) 1>tacopie.lib(self_pipe.obj) : error LNK2019: unresolved external symbol __imp_ioctlsocket referenced in function "public: __cdecl tacopie::self_pipe::self_pipe(void)" (??0self_pipe@tacopie@@QEAA@XZ) 1>tacopie.lib(self_pipe.obj) : error LNK2019: unresolved external symbol __imp_getsockname referenced in function "public: __cdecl tacopie::self_pipe::self_pipe(void)" (??0self_pipe@tacopie@@QEAA@XZ) 1>tacopie.lib(self_pipe.obj) : error LNK2019: unresolved external symbol __imp_htonl referenced in function "public: __cdecl tacopie::self_pipe::self_pipe(void)" (??0self_pipe@tacopie@@QEAA@XZ) 1>tacopie.lib(self_pipe.obj) : error LNK2019: unresolved external symbol __imp_recvfrom referenced in function "public: void __cdecl tacopie::self_pipe::clr_buffer(void)" (?clr_buffer@self_pipe@tacopie@@QEAAXXZ) 1>tacopie.lib(self_pipe.obj) : error LNK2019: unresolved external symbol __imp_sendto referenced in function "public: void __cdecl tacopie::self_pipe::notify(void)" (?notify@self_pipe@tacopie@@QEAAXXZ)

Are there any dependencies required for building? I am using Visual Studio 2015.

We have a sync_commit call that works fine most of the time, but on occasion it seems to hang on the following line:

m_sync_condvar.wait(lock_callback, [=] { return m_callbacks_running == 0 && m_callbacks.empty(); });

m_callbacks_running is 0 and m_callbacks is empty, but it looks like the condition variable is not being notified? It just waits forever and nothing makes progress. I'm not really sure how to debug this!

Hi there,

I really like the platform and thank you for continuing to maintain a great project.

I have a query though regarding Publishing as it may be broken in the latest build. Although I can subscribe to a channel fine no messages are actually received.. But I noticed that the debug window was showing an exception thrown by tacopie and a memory address. I can't locate the problem however.

I am using Redis 4.0.

Any suggestions please?

Thanks

I try to use blpop with timeout parameter as the following code:

int main(int argc, char* argv[]) {
  cpp_redis::client client;
  RedisInfo redis_info;
  redis_info.address = "127.0.0.1";
  redis_info.port = 6379;

  // This function is just init a redis client.
  if (!common::InitRedisClient(&client, redis_info)) {
    cout << "Establish connection to redis failed" << endl;
    return 0;
  } else {
    cout << "Establish connection to redis succeed" << endl;
  }

  vector<string> keys;
  keys.push_back("test");
  client.blpop(keys, 1, [](cpp_redis::reply& reply) {
    cout << "Blpop response: " << reply.as_string() << endl;
  });
  client.sync_commit();

  cout << "Blpop timeout" << endl;

  return 0;
}

As my understanding, program should print "Blpop timeout" after 1s and there are no data push to test list. But program seem to be block and never end. Is this expected behavior of blpop command with timeout?

When I run redis with localhost read/write works perfectly but with remote redis client hangs randomly. The stack trace points to conditonal wait on the mutex. I am yet to derive any conclusion but seems with small string it works fine but with big value 1mb trouble starts.. It just hangs ( wait)!
Any pointer would be real help!!

Below redis client program seg-faults on exit if redis-server is not available. I killed redis-server after the client started. Call stack from core dump is below.

#include <cpp_redis/cpp_redis>
#include <thread>
#include <chrono>

int main(void) 
{
  cpp_redis::client client;
  client.connect("127.0.0.1", 6379, nullptr, 0, 10, 1000);
  std::this_thread::sleep_for(std::chrono::seconds(5)); // kill redis-server during this sleep
  client.cancel_reconnect();
  return 0;
}

(gdb) bt #0 0x00007f6f7b23db63 in std::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_replace(unsigned long, unsigned long, char const*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x00000000004b2c78 in cpp_redis::sentinel::get_master_addr_by_name(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator >&, unsigned long&, bool) () #2 0x00000000004279f7 in cpp_redis::client::reconnect() () #3 0x00000000004268df in cpp_redis::client::connection_disconnection_handler(cpp_redis::network::redis_connection&) () #4 0x00000000004be0ab in tacopie::tcp_client::on_read_available(int) () #5 0x00000000004bc9cd in std::_Function_handler<void (), tacopie::io_service::process_rd_event(int const&, tacopie::io_service::tracked_socket&)::$_0>::_M_invoke(std::_Any_data const&) () #6 0x00000000004c1561 in tacopie::utils::thread_pool::run() () #7 0x00007f6f7b1d2733 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #8 0x00007f6f7b4a96db in start_thread (arg=0x7f6f7a76c700) at pthread_create.c:463 #9 0x00007f6f7a88e88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bear minimum code

Connect and reconnect code

`void RedisUtil::connect_callback(const std::string& host, std::size_t port, cpp_redis::client::connect_state status){ if (status == cpp_redis::client::connect_state::dropped) { std::unique_lockstd::mutex ulock(m_mutex); m_con_var.wait(ulock,std::bind(&RedisUtil::is_client_available,this)); release(); while(intialize(host,port)){}; } }

bool RedisUtil::intialize(const std::string &redis_host , const int redis_port ){ auto conn_call_wrap = std::bind( &RedisUtil::connect_callback,this,_1,_2,_3); redis_client.connect(redis_host, redis_port,conn_call_wrap); }`

Redis client get wrapper

           `std::lock_guard<std::mutex> guard(m_mutex);
	m_is_cli_avail = false;
	redis_client.get(key, getCallBack);
	redis_client.sync_commit();
	m_is_cli_avail = true;
	m_con_var.notify_one();`

I am looking for a better approach, any help will be gratefully welcome.