deepfryed / beanstalk-client Goto Github PK

hello deepfryed, would it be possible to officially support conan for this package?

for example, the Catch2 library has their package in the conan repository

• https://bintray.com/catchorg/Catch2/Catch2%3Acatchorg
• https://github.com/catchorg/Catch2/tree/master/.conan

create a pkgconfig file beanstalk-client library

I would appreciate a check on if a connection with beanstalk is active. This can be as simple as the following:

bool Beanstalk::Client::is_active() {
    return handle != -1;
}

The handle is reset to -1 when there is no connection, so this would work just fine.

When compiling with -std=c99 I get following error:

 beanstalk.c:65:41: error: dereferencing pointer to incomplete type
 beanstalk.c:66:16: error: dereferencing pointer to incomplete type
 beanstalk.c:67:32: error: dereferencing pointer to incomplete type

Please add BS_STATUS_CONNECTION_FAIL to distinguish connection problem and something else.

I ran valgrind on my application and several issues popped up involving Beanstalk::Client::reconnect(). I will put the report in a separate post in this issue.

I'm not entirely sure how to fix this, but I did notice the following when looking at the code.

When looking at the code, I notice that strings are passed by value. eg:

Client::Client(string host, int port, float secs) {
...
void Client::connect(string _host, int _port, float secs) {

In addition, in reconnect(), connect is called with the member values of host, port and float secs already stored in the instance, which values are then again used to set the exact members passed.

void Client::connect(string _host, int _port, float secs) {
...
    host         = _host;
    port         = _port;
    timeout_secs = secs;
...
}
...
 void Client::reconnect() {
    disconnect();
    connect(host, port, timeout_secs);
}

This looks like a roundabout way of reconnecting and might be improved by using const string referemces. Since these methods are exactly where the memory issues occur as reported by valgrind, cleaning up might go some way to solve them.

After running make install in the beanstalk-client directory, I attempt to compile my C++ application with g++ and get the following errors:

Undefined symbols for architecture x86_64:
  "Beanstalk::Client::put(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, int, int)", referenced from:
      _main in cc4Agvt5.o
  "Beanstalk::Client::Client(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, float)", referenced from:
      _main in cc4Agvt5.o
  "Beanstalk::Client::~Client()", referenced from:
      _main in cc4Agvt5.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

beanstalk.hpp is definately in my /usr/include path and I am compiling with g++ tailer.cpp

Why through poll instead of epoll to achieve?
As far as I know, epoll performance is better

Hi,

I've just installed beanstalk-client on a 64-bit openSUSE system. Doing 'sudo make install' puts the created library files into /usr/lib. It should go into /usr/lib64 instead, otherwise the libraries will not be found.

I looked in the makefile, the target lib directories are used in this part:

install: $(SHAREDLIB) $(STATICLIB)
  mkdir -p $(DESTDIR)/usr/include $(DESTDIR)/usr/lib $(DESTDIR)/usr/lib/pkgconfig
  cp beanstalk.h $(DESTDIR)/usr/include
  cp beanstalk.hpp $(DESTDIR)/usr/include
  cp $(SHAREDLIB) $(DESTDIR)/usr/lib/$(SHAREDLIB).$(VERSION)
  cd $(DESTDIR)/usr/lib && ln $(LNOPTS) $(SHAREDLIB).$(VERSION) $(SHAREDLIB).1
  cd $(DESTDIR)/usr/lib && ln $(LNOPTS) $(SHAREDLIB).$(VERSION) $(SHAREDLIB)
  cp $(STATICLIB) $(DESTDIR)/usr/lib/$(STATICLIB).$(VERSION)
  cd $(DESTDIR)/usr/lib && ln $(LNOPTS) $(STATICLIB).$(VERSION) $(STATICLIB).1
  cd $(DESTDIR)/usr/lib && ln $(LNOPTS) $(STATICLIB).$(VERSION) $(STATICLIB)
  cp beanstalk-client.pc $(DESTDIR)/usr/lib/pkgconfig/libbeanstalk.pc
  sed -i -e 's/@VERSION@/$(VERSION)/' $(DESTDIR)/usr/lib/pkgconfig/libbeanstalk.pc

For my specific install, the lib directory should be /usr/lib64 instead.

Please adjust the makefile so that this path is defined automatically for the platforms that need it. Also, please make it so that the lib path can be easily adjusted in one place, eg in a variable - this as a fallback for previous request.

Apart from this, the compile and install goes fine (after I changed the lib path).

Thanks,

Wim.

Need to package this (deb, rpm etc.).

Here is a program that demonstrates the issue:
https://gist.github.com/matthill/635f3f572246dc37e11e242bdb1ee733

Steps for reproducing:

1. Start beanstalkd
2. Start this program
3. Stop beanstalkd

Bad behavior: program aborts due to SIGPIPE being sent to the process
Good behavior: program should throw an exception or return a variable indicating that we need to tru reconnecting to beanstalkd.

I will send a patch and PR shortly for your review.

Hi there,

Valgrind is telling me that I have a 'definitely lost' block in bs_put, which is created on the following line:

packet = bs_message_packet_new(command_bytes + bytes + 3);

Admittedly, my code appears to be in an error situation and is likely closing down at the time of the call to bs_put(). However, I'm determined to have a situation in which no memory leaks at all are present in my application.

Would you mind adjusting bs_put() so that it ALWAYS cleans up the given packet, even if one of the error situations at the bottom of the function are reached?

Thanks!

Recently, I have the following situation:

I'm putting a job on a beanstalk queue using Beanstalk::Client::put(). Within this method, for some reason, the following call is made:

message = bs_recv_message(fd, BS_MESSAGE_NO_BODY);

Where BS_MESSAGE_NO_BODY has value 0.
What sometimes happens, is that bs_recv_message() blocks indefinitely on the following line:

ret = recv(fd, message->status, status_max - 1, 0);

This is to be expected, since the last parameter is zero. These are the flags for the call and MSG_DONTWAIT is not specified in this call. I can also see that O_NONBLOCK is set in bs_connect_with_timeout() for the particular case when a timeout value is specified.

Obviously, hanging indefinitely here on send is not desired behaviour. For this reason, I have the following questions:

• Why is it necessary to attempt to retrieve data from the socket when the goal is to send data to the socket?
• Is there a reason why the call to recv() is totally blocking when sending? I understand that the blocking may occur when trying to receive jobs, but blocking on sending doesn't make sense.
• Is it possible to circumvent this blocking behaviour on send?

If I have a request here, it's that the call to recv() in bs_recv_message() is made non-blocking, e.g.:

ret = recv(fd, message->status, status_max - 1, MSG_DONTWAIT);

Is it possible to do this? If not, could you motivate why and please give an alternative solution to this issue?

Thanks in advance,

Wim.

$ make
gcc -Wall -Wno-sign-compare -g -I. -fPIC -c -o beanstalk.o beanstalk.c
g++ -Wall -Wno-sign-compare -g -I. -fPIC -c -o beanstalkcpp.o beanstalk.cc
g++ -shared -Wl,-soname,libbeanstalk.so.1 -o libbeanstalk.dylib beanstalk.o beanstalkcpp.o
ld: unknown option: -soname
collect2: ld returned 1 exit status
make: *** [libbeanstalk.dylib] Error 1

What version of gcc do you use? I'm using gcc 4.2.1 on OS X. The -Wno-signed-compare breaks the compile for me.

make beanstalk.o
gcc -Wall -Wno-signed-compare -g -I. -fPIC -c -o beanstalk.o beanstalk.c
cc1: error: unrecognized command line option "-Wno-signed-compare"
make: *** [beanstalk.o] Error 1

Googling for -Wno-signed-compare gets no related hits.

I'm rusty on my C builds, but did you mean -Wno-sign-compare?

BTW, would you be interested in me making a pull request for an adaptation of your makefile that supports Macs as well?

Cheers,
Tony

What would be the best way to detect if we are connected to beanstalkd ?, Currently
I just assume if status from bs_put is BS_STATUS_FAIL we aren't connected.
Is this correct way of doing it or is there a better way ?

beanstalk-client/beanstalk.c:267:74: error: use of undeclared identifier 'MSG_NOSIGNAL'
return send(fd, message, size, bs_poll ? MSG_DONTWAIT|MSG_NOSIGNAL : MSG_NOSIGNAL);

MSG_NOSIGNAL is not defined on Mac OSX - introduced by #31