Hello @sgieseking,

I have successfully compiled the anyrpc examples with log4cplus on Windows with Visual Studio 2015. The examples are running fine and the logging is working. But the application crashes on exit. I found an issue on the log4cplus project page having the same error. However I was not able to use this information to eliminate the crash. Simply adding log4cplus::Initializer initializer; to the top of the main of exampleServer does not fix the error. Can you give me a few pointers how the error can be corrected?

Thank you in advance for your time and help.

Greetings Jan

Hi, I'm launching the exampleServer and exampleClient provided with this project and compiled with VisualStudio 2015 under Win7 64bit by these command line calls:

start anyrpc\build\bin\Debug\exampleServer.exe jsontcp 9000 100
start anyrpc\build\bin\Debug\exampleClient.exe jsontcp 127.0.0.1 9000

At the moment the client finishes its job, the server displays the following warning: In my own project, I noticed that this warning always occurs, if a Jsontcp-client calls the close() function. It's probably not even related to the target system and compiler, because it also happens on linux with gcc.

Are you able to reproduce this warning?

XmlRpc.net will send <params /> when there is no parameters. But AnyRPC can't parse it and return parse error.

For example:

<!-- Request -->
<?xml version="1.0"?>
<methodCall>
  <methodName>
    MethodName
  </methodName>
  <params/>
</methodCall>

<!-- Response -->
<?xml version="1.0" encoding="utf-8"?>
    <methodResponse>
        <fault>
            <value>
                <struct>
                    <member>
                        <name>
                            faultCode
                            </name>
                        <value>
                            <i4>
                                -32700
                                </i4>
                            </value>
                        </member>
                    <member>
                        <name>
                            faultString
                            </name>
                        <value>
                            Parse error
                            </value>
                        </member>
                    </struct>
                </value>
            </fault>
        </methodResponse>

Hi, AnyRpc work fine server/client on c++. But when I use it with another Server/Client on Javascript+Node on JsonHttp is still working fine. But I used with JsonTcp no data received on server. My Javascript code (Server and Client) work fine together on jsontcp mode also, like the AnyRpc examples. But to mix or cross it that only work on JsonHttp. The Javascript client for example is very simple like: var client = jayson.client.tcp({port: 9000 }) client.request('add', [3.0, 5.0], function(err,response)){... throw ....}

Any idea ?

Thanks

Hi, I've run into a threading issue with the method manager, which was hard to find but can easily be forced to occur. First I'll give a short description how to reproduce the error, afterwards I'll explain and give my thoughts.

Reproduction

1. Use the exampleServer and exampleClient from anyrpc examples. I used the single threaded JsonTcpServer, but the error probably occurs for all threaded servers.
2. In method.cpp extend the ExecuteMethod like this:

    [...]
    if (it == methods_.end())
        return false;
    std::cout << "MethodManager paused..." << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(15));
    std::cout << "MethodManager going on." << std::endl;
    it->second->Execute(params,result);
    [...]

3. In exampleServer.cpp change the line this_thread::sleep_for( chrono::seconds(timeout) ); to the following lines:

    this_thread::sleep_for( chrono::seconds(10) );
    std::cout << "Remove subtract now..." << std::endl;
    methodManager->RemoveMethod("add");
    std::cout << "Server changes finished." << std::endl;
    this_thread::sleep_for(chrono::seconds(30));
    std::cout << "Server shutting down..." << std::endl;

4. Start the server and immediatly afterwards the client. The client will get plenty of timeouts, but this doesn't matter. On the server you'll get at "map/set iterator not dereferencable" error (at least for VS2015).

Explanation and Thoughts Inside the server's worker thread incoming rpc-commands from client are directed to the ExecuteMethod function. However this access is not protected by any mutex, so nothing prevents the main thread (or any other thread) from accessing MethodManager. By adding the sleep in ExecuteMethod, I'm just "increasing" the possibility of a thread-change at this point.

If at this point the RemoveMethod function is called from main thread, the issue is obvious. The iterator is invalidated (and besides we do not have the corresponding function that should be executed anymore).

Note, that this issue does occur for any MethodManager function, because they all use iterators which might be invalidated. However (if I see this correctly) the invalidation does only occur for RemoveMethod. In AddMethod this issue does not occur, because a map is used and map-iterators aren't invalidated on insertion (unlike e.g. vectors). Still you could think of other problems, like adding multiple methods at the same time, listing and adding at the same time, ...

In general I would propose the usage of a mutex, which prevents from multiple access to any of the member functions, but I wanted to hear your oppinion first. The following problems might occur:

• I'm not sure if a mutex might collide with any server type. Would there be a problem, if the ExecuteMethod-function was mutexed (e.g. because it is called multiple times in parallel)? If so, one could maybe use the std::shared_mutex (C++17)...
• The call of member-functions would not be possible from within any other member-function. E.g. it would not be possible inside a rpc-command to ask for a list of all available commands. One could use a std::recursive_mutex (C++11) to allow this, but recursive mutexes are a controversial topic...

Any comments on these topics?

PS: I'm aware that the RemoveMethod function was added by one of my pull requests, but without it one would reactivate the problem of deleted references (discribed in #24).

You might want to create a TCP-TP-server of a specific subtype while specifying the number of used threads. e.g.: const unsigned numThreads = 10; Server *server = 0; server = new JsonTcpServer(numThreads);

This was not possible without these changes.

hi, I try to build your lib again. But now the compilation failed. Maybe after your last merge (24/01/2017). why you did not use a Branch or Tag to keep the old version code and the new with the modifications.

std::condition_variable condVarDelayedRemove_; ^ /data/IPC_TESTS/anyrpc/src/method.cpp: In member function ‘bool anyrpc::MethodManager::RemoveMethod(const string&, bool)’: /data/IPC_TESTS/anyrpc/src/method.cpp:114:17: error: ‘condVarDelayedRemove_’ was not declared in this scope condVarDelayedRemove_.wait(lock); ^ /data/IPC_TESTS/anyrpc/src/method.cpp: In member function ‘void anyrpc::MethodManager::ExecuteMethod_FollowUpOperations(anyrpc::Method*)’: /data/IPC_TESTS/anyrpc/src/method.cpp:167:9: error: ‘condVarDelayedRemove_’ was not declared in this scope condVarDelayedRemove_.notify_all(); // notify waiting calls of remove method (if any) ^ make[2]: *** [src/CMakeFiles/anyrpc.dir/method.cpp.o] Error 1 make[1]: *** [src/CMakeFiles/anyrpc.dir/all] Error 2 make: *** [all] Error 2

We're using the tcp-messagepack implementation of anyrpc with enabled threading.

Upon system shutdown we're closing down the connections and sometimes it happens that select() hangs up. This can be identified using the remote debugger for ARM. We're using a timeout of 100 ms.

Furthermore, using the variable _threadRunning as of type bool is not threadsafe and should be implemented as std::atomic.

A possible workaroung might be to look at signals for the usage with select(). http://man7.org/linux/man-pages/man2/select_tut.2.html

Has anyone considered this solution?

Have you guys considered adding an option to use INADDR_LOOPBACK instead of INADDR_ANY in Socket::Bind()? The latter binds to 0.0.0.0 which triggers firewalls, while the loopback option binds to the local address without additional firewall attention.

I'm using this library as a part of Spix project, which is UI automation library and all the network communication is done locally on the host, so those firewall's notifications are quite annoying. It would be really nice to have a "local only" option somewhere in AnyRPC please :)

Thank you.

Hi, I'm launching the exampleServer and exampleClient provided with this project and compiled with gcc under RHEL 7.0 by these command line calls: build/bin/exampleServer jsontcp 9000 9000 buid/bin/exampleClient If I run the client program for 100 times, the server response correctly. However, the file descriptor occupied by the exampleServer is keep growing, which can launch following command line: ll /proc/$(pidof exampleServer)/fd So If I want to open another file such a plain text file by rpc call, I may fail to open the file since the file descriptor is all occupied after many rpc call. I wonder when the server will close the file descriptor ( socket fd ). How can I solve this problem?

My motivation for this functionality was, that I needed to know ip and port of my connecting client and server. I'm working with a multi client- multi server network and therefor having this information is usefull for logging and debugging purposes. Besides it can be used to start the second side of a two-directional rpc-interface.

As described in the commit message, the Socket provides basic functionality while Server, Client and Connection just pass the request on.

Asking for ip and port however is not possible, before the connection is established. Besides implicit start of a connection when calling Notify, Call or Post, I didn't find any functionality which actually establishes a connection. I figured, that an empty dummy message for starting connection is not the best way, so I provided the Client::Start() functionality. Maybe you have a closer look on it, I'm not 100% sure, if it is implemented correctly. In particular I'm not sure with gettimeofday(&startTime_, 0);, but without the call of Connect() fails.

Of course it's not required in general, but only if you want to get your port / ip before sending first tcprpc message.

The functionality is tested with Visual Studio 2015, Windows 7 and gcc 4.9.2, Linux.

Hi, while developing multi-thread applications naming of threads (e.g. for debugging) has proven to be quite useful. In the following I'd like to propose some additions to your library. Use them if you like them, feel free to simply close this issue if you think otherwise...

Header threadName.h would be:

#ifndef THREAD_NAME_H_
#define THREAD_NAME_H_

#include <thread>

namespace misc
{
	/// name current thread
	void SetThreadName(const std::string& threadName);

	/// name thread identified by thread-handle
	void SetThreadName(std::thread& thread, const std::string& threadName);
}

#endif /* THREAD_NAME_H_ */

Source threadName.cpp would be the following, where the windows part is mainly based on this MSDN example (it appears "dirty", but I didn't find any cleaner solution):

#include "anyrpc/threadName.h"

#ifdef _WIN32 /* WINDOWS */

	#include <windows.h>  
	const DWORD MS_VC_EXCEPTION = 0x406D1388;

	#pragma pack(push,8)  
	typedef struct tagTHREADNAME_INFO
	{
		DWORD dwType;		// Must be 0x1000.  
		LPCSTR szName;		// Pointer to name (in user addr space).  
		DWORD dwThreadID;	// Thread ID (-1=caller thread).  
		DWORD dwFlags;		// Reserved for future use, must be zero.  
	} THREADNAME_INFO;
	#pragma pack(pop)

	void SetThreadName(DWORD dwThreadID, const char* threadName) {
		THREADNAME_INFO info;
		info.dwType = 0x1000;
		info.szName = threadName;
		info.dwThreadID = dwThreadID;
		info.dwFlags = 0;
	#pragma warning(push)  
	#pragma warning(disable: 6320 6322)  
		__try
		{
			RaiseException(MS_VC_EXCEPTION, 0, sizeof(info) / sizeof(ULONG_PTR), (ULONG_PTR*)&info);
		}
		__except (EXCEPTION_EXECUTE_HANDLER)
		{
		}
	#pragma warning(pop)  
	}

	namespace misc
	{
		void SetThreadName(const std::string& threadName)
		{
			::SetThreadName(GetCurrentThreadId(), threadName.c_str());
		}

		void SetThreadName(std::thread& thread, const std::string& threadName)
		{
			DWORD threadId = ::GetThreadId(static_cast<HANDLE>(thread.native_handle()));
			::SetThreadName(threadId, threadName.c_str());
		}
	}

#else /* LINUX */

	#include <sys/prctl.h>

	namespace misc
	{
		void SetThreadName(const std::string& threadName)
		{
			::prctl(PR_SET_NAME, threadName.c_str(), 0, 0, 0);
		}

		void SetThreadName(std::thread& thread, const std::string& threadName)
		{
			auto handle = thread.native_handle();
			::pthread_setname_np(handle, threadName.c_str());
		}
	}

#endif

Obviously this is not for MacOS yet...

Using the above header and source one could for example add this line to StartThread() in server.cpp:

misc::SetThreadName(thread_, "AnyRpcServer");

Adding such a line to all thread creations allows an easy recognition of different threads in a multi-thread-environment and also thread-name-dependent breakpoints (the latter at least in VS).

Hi,

if I figured it correctly, anyrpc-logging is not working with unicode enabled.

Log4cplus itself supports unicode, for example I was building (on Win7 64bit, VS2015) with

cmake -DBUILD_SHARED_LIBS:BOOL=TRUE -DWITH_UNIT_TESTS=OFF -DLOG4CPLUS_BUILD_TESTING=OFF -DUNICODE=ON -DLOG4CPLUS_BUILD_LOGGINGSERVER=OFF -DLOG4CPLUS_SINGLE_THREADED=ON

However setting up anyrpc via

cmake -DBUILD_EXAMPLES=OFF -DBUILD_WITH_LOG4CPLUS=ON -DBUILD_WITH_WCHAR=ON -DBUILD_WITH_THREADING=ON -DUNICODE=ON -DLOG4CPLUS_LIBRARY_RELEASE=....\log4cplus\build\src\Release\log4cplusU.lib -DLOG4CPLUS_LIBRARY_DEBUG=....\log4cplus\build\src\Debug\log4cplusUD.lib

leads to a project file, that can't be compiled (note that I provided the correct libs from log4cplus, however you might need to manually add the UNICODE preprocessor define to anyrpc project).

When compiling the anyrpc-project one gets multiple errors like

binary operator '<<': no operator found which takes a right-hand operand of type 'std::string' (or there is no acceptable conversion)

or

'TimeLogger::TimeLogger(const TimeLogger &)' : cannot convert argument n from 'const char [1]' to 'log4cplus::tstring &'.

These errors are caused by calling log4cplus-macros, which obviously expect wchar (or corresponding strings) when compiled with UNICODE-preprocessor define. However the calls by anyrpc are done with simple chars, often fixed strings like "this is an example".

One solution for this problem would be, to use something like TCHAR and _T("my example") (these two only exist in Visual Studio as far as I know), but one would need to change all the logs accordingly.

For myself I found another "solution": In fact I don't really want unicode-logging, but I need the unicode-define enabled in my main project, because it is working with QT and QT needs unicode. So I just compile the dlls for anyrpc & log4cplus without UNICODE-preprocessor defined. In order to include correct headers in my main project, I changed the following lines in logger.h:

# ifdef UNICODE # undef UNICODE # define UNICODE_DISABLED_BECAUSE_ANYRPC_LOGGING_WITH_UNICODE_NOT_SUPPORTED # endif # include <log4cplus/log4cplus.h> # define InitializeLogger() \

log4cplus::Initializer initializer; \
log4cplus::PropertyConfigurator config(LOG4CPLUS_TEXT("log4cplus.properties")); \
config.configure();

# ifdef UNICODE_DISABLED_BECAUSE_ANYRPC_LOGGING_WITH_UNICODE_NOT_SUPPORTED # undef UNICODE_DISABLED_BECAUSE_ANYRPC_LOGGING_WITH_UNICODE_NOT_SUPPORTED # define UNICODE # endif

Obviously this is neither the cleanest nor a general solution, but this way UNICODE is defined everywhere (where QT needs it) except for the anyrpc / log4cplus part.

Any comments on this topic? Maybe I missed a point or there is a better way to get anyrpc running with unicode?