I have a server which uses boost.asio services. I use boost.log for logging with an asynchronous sink. The asio_io_service gets started within an own thread. The logger gets initialized in the main thread before starting the server. The server accepts connections with async_accept and reads and sends messages also asynchronously.
Now I have the problem, that the logger logs only messages when the server is doing something, e.g. receiving messages. When I log a message after logger initialization and before starting the server I can see this log message only after the first message was received by the server. But I want to log messages even when no server actions happen. Have you an idea what the problem is and how I can solve it?
Okay, the related stackoverflow-questions gave me the answer :) It was the by default disabled auto_flush. So this single line in the logger initialization was the solution:
sink->locked_backend()->auto_flush(true);
Related
Official gRPC documentation for client streaming states that:
The server sends back a single response, typically but not necessarily after it has received all the client’s requests...
What I'm trying to do is to catch server response in the middle of the stream to stop sending more data.
In Go I can spin up a new goroutine listening for the message from the server using RecvMsg, but I can't find a way to do the same in C++. It looks like ClientWriter doesn't offer this kind of functionality.
One solution would be to have a bidirectional stream but was wondering if there is any other way to achieve this in C++.
Once the response and status are sent by the server and received back at the client(i.e., the client-side gRPC stack) , subsequent attempts to Write() will start failing. The first failing Write() is the signal to the client that it should stop Writing and Finish the RPC.
So the two options here are:
1. Wait for a Write to fail, then call finish to receive the Server's response and status.
2. Switch to Bidirectional Streaming if the client really wants to read the response from the server before calling Finish.
I am working on C++ kafka client librdkafka. Looking into the example https://github.com/edenhill/librdkafka/blob/master/src-cpp/rdkafkacpp.h and https://github.com/edenhill/librdkafka/blob/master/examples/rdkafka_example.cpp, it seems that there is no process of connecting to broker? How to do some reconnect staff for these connection errors? How to check the connection status?
librdkafka abstracts all broker connectivity from the application, it will attempt to always keep a connection to each known broker (either learnt through metadata.broker.list or by the broker list returned from the first bootstrap brokers).
Upon connection error librdkafka will attempt to connect again, forever.
If none of brokers can be connected to the ALL_BROKERS_DOWN event will be triggered but there is currently no corresponding event for when brokers being to come back online.
The application doesn't need to worry though since librdkafka takes care of all reconnects and message retransmissions in the background and it will keep trying to get the messages produced until either message.timeout.ms or message.send.max.retries are exceeded.
There's more information on this in the introduction guide:
https://github.com/edenhill/librdkafka/blob/master/INTRODUCTION.md
I just learned websockets but am still c++ ignorant.
I'm using websocket++ 0.3X, and it is a veritable godsend (can't wait for 1.0). If there are multiple concurrent connections, and one client sends the server a message, will the message trigger the handlers of all other clients? If not, how can this be done? (Is this multithreading?)
What I want to do is the obvious: update the database via a message from a client then update any other clients currently viewing the fields updated.
Sources:
http://www.zaphoyd.com/websocketpp/
https://github.com/zaphoyd/websocketpp/wiki
The on_message handler will be called only in the connection that received the message. That connection is responsible for updating the database and signaling to your program to send an update out to all other clients.
Take a look at the broadcast server example here: http://www.zaphoyd.com/websocketpp/manual/common-patterns/server-initiated-messages for a simple example of how to set this up.
I'm using ActiveMQ CPP 5.2.3 if it matters.
I have JMS producer that connects using failover transport to JMS network of brokers.
When I call connection->start() it hangs up (see AMQ-2114).
If I skip connection start() and call connection->createSession(), than this call is blocked too.
The requirement is that my application will try forever to connect to broker(s).
Any suggestions/workarounds?
NOTE:
This is not duplicate of here, since I'm talking about C++ and such solutions as embedded broker, spring are not available in C++.
This is normal when the connection is awaiting a transport to connect to the broker. The start method must send the client's id info to the broker before any other operation, so if no connection is present it must block. You can set some options on the failover transport like the startupMaxReconnectAttempts option to control how long it will try to connect before reporting a failure. See the URI configuration page:
http://activemq.apache.org/cms/configuring.html
I need a client networking thread to be able to respond both to new messages to be transmitted, and the receipt of new data on the network. I wish to avoid this thread performing a polling loop, but rather to process only as needed.
The scenario is as follows:
A client application needs to communicate to a server via a protocol that is largely, but not entirely, synchronous. Typically, the client sends a message to the server and blocks until a response is received.
The server may process client requests asynchronously, in which case the response to client
is not a result, but a notification that processing has begun. A result message is sent to to the client at some point in the future, when the server has finish processing the client request.
The asynchronous result notifications can arrive at the client at any time. These notifications need processed when they are received i.e. it is not possible to process a backlog only when the client transmits again.
The clients networking thread receives and processes notifications from the server, and to transmit outgoing messages from the client.
To achieve this, I need to to make a thread wake to perform processing either when network data is received OR when a message to transmit is enqueued into an input queue.
How can a thread wake to perform processing of an enqueued work item OR data from a socket?
I am interested primarily in using the plain Win32 APIs.
A minimal example or relevant tutorial would be very welcome!
An alternative to I/O Completion Ports for sockets is using WSAEventSelect to associate an event with the socket. Then as others have said, you just need to use another event (or some sort of waitable handle) to signal when an item has been added to your input queue, and use WaitForMultipleObjects to wait for either kind of event.
You can set up an I/O Completion Port for the handles and have your thread wait on the completion port:
http://technet.microsoft.com/en-us/sysinternals/bb963891.aspx
Actually, you can have multiple threads wait on the port (one thread per processor usually works well).
Following on from Michael's suggestion, I have some free code that provides a framework for IO Completion Port style socket stuff; and it includes an IOCP based work queue too. You should be able to grab some stuff from it to solve your problem from here.
Well, if both objects have standard Windows handles, you can have your client call WaitForMultipleObjects to wait on them.
You might want to investiate splitting the servicing of the network port off onto its own thread. That might simplify things greatly. However, it won't help if you just end up having to synchonize something else between that new thread and your main one.