jsonrpc-cpp-devel Mailing List for JsonRpc-Cpp

Hi Anoop!

On 12/18/2015 08:01 AM, Anoop Ravi wrote:
> Hi,
> 
>  
> 
>           I could find a bug in jsonrpc-cpp module while trying to adopt
> ipv6 capability to my application. I tried to bind my server application
> to all ip addresses (ipv4 and v6 at the same time) using “::”. I found a
> comment line in “src/networking.cpp” which says “accept IPv6 OR IPv4 on
> the same socket”. As the comment says, the server socket should accept
> both V4 and V6 in the same socket. So I tried to communicate to my
> server application using its IPV4 address, It didn’t work while
> connecting with its V6 counterpart was working.
> 
>  

The TCP implementation was kind of prototype. That's why it is still on
the develop branch. It is contributed code by a third-party. I also
detected lots of flaws in it and probably I will remove it again, until
I have the time to give it a deep review and fix the bugs.



> 
>          This made me peek into networking.cpp source code to see the
> socket options. In “setsockopt()”, a parameter decides the flexibility
> of the socket to accept both ip versions or not.
> 
>  
> 
> /on = 1;   /
> 
> /setsockopt//(//sock//,// IPPROTO_IPV6//,//IPV6_V6ONLY//,// //&//on//,// //sizeof//(//on//));///
> 
>        
> 
>     Here the variable is set to value ‘1’, which doesn’t allow both ip
> versions simultaneously. This contradicts with the comment given there.
> 
>  
> 
> /on //=// //0//;/
> 
> /setsockopt//(//sock//,// IPPROTO_IPV6//,//IPV6_V6ONLY//,// //&//on//,// //sizeof//(//on//));///
> 
>  
> 
>      Instead its value should be ‘0’. Modifying this value made my
> application work as expected.
> 
>  

Thanks for taking the time reporting this.

> 
>         I think this is a bug in the implementation. I couldn’t find any
> bugzilla or other bug tracking tools. Hence posting it here.
> 
>  

The library is officially maintained at Github. If you refuse to sign-up
on GitHub (which I would totally understand), you can always post your
findings here on the mailing list.

https://github.com/cinemast/libjson-rpc-cpp

> 
> Best Regards,
> 
> Anoop Ravi
> 
>  

Greetings
Peter

Hi,
 
          I could find a bug in jsonrpc-cpp module while trying to adopt ipv6 capability to my application. I tried to bind my server application to all ip addresses (ipv4 and v6 at the same time) using “::”. I found a comment line in “src/networking.cpp” which says “accept IPv6 OR IPv4 on the same socket”. As the comment says, the server socket should accept both V4 and V6 in the same socket. So I tried to communicate to my server application using its IPV4 address, It didn’t work while connecting with its V6 counterpart was working.
 
         This made me peek into networking.cpp source code to see the socket options. In “setsockopt()”, a parameter decides the flexibility of the socket to accept both ip versions or not.
 
on = 1;   
setsockopt(sock, IPPROTO_IPV6,IPV6_V6ONLY, &on, sizeof(on));
       
    Here the variable is set to value ‘1’, which doesn’t allow both ip versions simultaneously. This contradicts with the comment given there.
 
on = 0;
setsockopt(sock, IPPROTO_IPV6,IPV6_V6ONLY, &on, sizeof(on));
 
     Instead its value should be ‘0’. Modifying this value made my application work as expected.
 
        I think this is a bug in the implementation. I couldn’t find any bugzilla or other bug tracking tools. Hence posting it here.
 
Best Regards,
Anoop Ravi
 

Hi,

This is already fixed in SVN trunk repository : 
http://sourceforge.net/p/jsonrpc-cpp/code/HEAD/tree/trunk/src/jsonrpc_tcpserver.cpp

Thanks anyway.

Regards,
--
Seb

Le 13/07/2014 07:41, Markus Gaugusch a écrit :
> Hi,
>
> I'm using jsonrpc-cpp-0.4 and found a major bug. After some time my
> applicaiton (using TcpServer) stopped working with 100% CPU load. I found
> out that it used many many file descriptors due to not closing the client
> sockets.
>
> The fix is rather simple:
> --- src/jsonrpc_tcpserver.cpp.orig	2014-07-13 07:39:55.237060802
> +0200
> +++ src/jsonrpc_tcpserver.cpp	2014-07-13 06:17:27.462943211 +0200
> @@ -185,6 +185,7 @@
>            /* remove disconnect socket descriptor */
>            for(std::list<int>::iterator it = m_purge.begin() ; it != m_purge.end() ; it++)
>            {
> +          ::close((*it));
>              m_clients.remove((*it));
>            }
>
>
> thanks,
> Markus
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jsonrpc-cpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsonrpc-cpp-devel

Hi,

I'm using jsonrpc-cpp-0.4 and found a major bug. After some time my 
applicaiton (using TcpServer) stopped working with 100% CPU load. I found 
out that it used many many file descriptors due to not closing the client 
sockets.

The fix is rather simple:
--- src/jsonrpc_tcpserver.cpp.orig	2014-07-13 07:39:55.237060802 
+0200
+++ src/jsonrpc_tcpserver.cpp	2014-07-13 06:17:27.462943211 +0200
@@ -185,6 +185,7 @@
          /* remove disconnect socket descriptor */
          for(std::list<int>::iterator it = m_purge.begin() ; it != m_purge.end() ; it++)
          {
+          ::close((*it));
            m_clients.remove((*it));
          }


thanks,
Markus

If you have install manually (in /usr/local/), maybe add 
-L/usr/local/lib to the library path of the SConstruct.

Normally on many Linux distributions, there is a jsoncpp package.

Le 07/11/2013 01:19, Sveinn Valfells a écrit :
> Hello,
>
> Checked out revision 275 of jsoncpp, installs without issues.
>
> Checked out revision 68 of json-rcp, gives the following error:
>
> <error>
>
> scons: Building targets ...
> g++ -o libjsonrpc.so -shared src/jsonrpc_handler.os
> src/jsonrpc_server.os src/jsonrpc_client.os src/jsonrpc_udpserver.os
> src/jsonrpc_tcpserver.os src/jsonrpc_udpclient.os
> src/jsonrpc_tcpclient.os src/netstring.os src/system.os
> src/networking.os src/jsonrpc_httpclient.os -ljson -lcurl -lpthread
> /usr/bin/ld: cannot find -ljson
> collect2: ld returned 1 exit status
> scons: *** [libjsonrpc.so] Error 1
> scons: building terminated because of errors.
>
> </error>
>
> I am following the instructions for JsonRpc-Cpp here
>
> http://jsonrpc-cpp.sourceforge.net/index.php?n=Doc.UserDocumentation
>
> (revision 68)
>
> the only dependency listed is for scons and JsonCpp, JsonCpp I got here
>
> http://jsonrpc-cpp.sourceforge.net/index.php?n=Doc.FAQ
>
> (revision 275)
>
> It would appear to me that the json library "-ljson" should be installed
> with JsonCpp, but isn't - at least not in a way g++ can find it.
>
> Don't know my way around scons, any suggestions on where to look for the
> missing library?
>
> Thanks!!
>
> Sveinn "Swain" Valfells
> London, UK
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Jsonrpc-cpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsonrpc-cpp-devel

Hello,

Checked out revision 275 of jsoncpp, installs without issues.

Checked out revision 68 of json-rcp, gives the following error:

<error>

scons: Building targets ...
g++ -o libjsonrpc.so -shared src/jsonrpc_handler.os 
src/jsonrpc_server.os src/jsonrpc_client.os src/jsonrpc_udpserver.os 
src/jsonrpc_tcpserver.os src/jsonrpc_udpclient.os 
src/jsonrpc_tcpclient.os src/netstring.os src/system.os 
src/networking.os src/jsonrpc_httpclient.os -ljson -lcurl -lpthread
/usr/bin/ld: cannot find -ljson
collect2: ld returned 1 exit status
scons: *** [libjsonrpc.so] Error 1
scons: building terminated because of errors.

</error>

I am following the instructions for JsonRpc-Cpp here

http://jsonrpc-cpp.sourceforge.net/index.php?n=Doc.UserDocumentation

(revision 68)

the only dependency listed is for scons and JsonCpp, JsonCpp I got here

http://jsonrpc-cpp.sourceforge.net/index.php?n=Doc.FAQ

(revision 275)

It would appear to me that the json library "-ljson" should be installed 
with JsonCpp, but isn't - at least not in a way g++ can find it.

Don't know my way around scons, any suggestions on where to look for the 
missing library?

Thanks!!

Sveinn "Swain" Valfells
London, UK

Please post the code where you register the function.

Can you call any of the other RPC calls, except system.describe?
If not, you have a problem in your server-side function registration.

// Fredrik


On Thu, Sep 26, 2013 at 9:20 PM, Anoop Ravi <ano...@gm...> wrote:

> Hi All,
>
>     I got an issue while using jsonrpc library. i am trying to call
> the function getConnectedDevices which is registered with jsonrpc
> server. But it is showing message as "Method not found.". But in
> system.describe call, this function is showing as registered one. Can
> anyone know why this is happening?
>
> Query is:
> {"id":8,"jsonrpc":"2.0","method":"getConnectedDevices","param1":""}
>
> Received: {"error":{"code":-32601,"message":"Method not
> found."},"id":8,"jsonrpc":"2.0"}
>
> Query is: {"id":7,"jsonrpc":"2.0","method":"system.describe","param1":""}
>
> Received:
> {"id":7,"jsonrpc":"2.0","result":{"LoadModule":null,"UnloadModule":null,"getConnectedDevices":null,"setClientRoute":null,"system.describe":{"description":"List
> the RPC methods available","parameters":null,"returns":"Object that
> contains description of all methods registered"}}}
>
> --
> Anoop.
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Jsonrpc-cpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsonrpc-cpp-devel
>

Hi All,

    I got an issue while using jsonrpc library. i am trying to call
the function getConnectedDevices which is registered with jsonrpc
server. But it is showing message as "Method not found.". But in
system.describe call, this function is showing as registered one. Can
anyone know why this is happening?

Query is: {"id":8,"jsonrpc":"2.0","method":"getConnectedDevices","param1":""}

Received: {"error":{"code":-32601,"message":"Method not
found."},"id":8,"jsonrpc":"2.0"}

Query is: {"id":7,"jsonrpc":"2.0","method":"system.describe","param1":""}

Received: {"id":7,"jsonrpc":"2.0","result":{"LoadModule":null,"UnloadModule":null,"getConnectedDevices":null,"setClientRoute":null,"system.describe":{"description":"List
the RPC methods available","parameters":null,"returns":"Object that
contains description of all methods registered"}}}

-- 
Anoop.

Ok sorry! I didn't look there, my bad. Can i ask: why isn't it released yet? Its a fairly common used feature i think. I don't mean to be rude, and i appreciate your work!
It works in our application with around 40 methods!

Would you currently advise to use the SVN trunk version in a production environment?

Verstuurd vanaf mijn iPhone

Op 28 aug. 2013 om 18:00 heeft "Sebastien Vincent" <seb...@cp...<mailto:seb...@cp...>> het volgende geschreven:

Hi,

IIRC I fix this bug in SVN trunk some month ago.

Regards,
--
Seb

Le 28/08/2013 16:36, Johan Gielens a écrit :
Hello,

I found a bug in jsonrpc_tcpserver.cpp on line 139:

tv.tv_usec = (ms % 1000 ) / 1000;
should be:
tv.tv_usec = (ms % 1000 ) * 1000;

If the WaitMessage function is used in a loop, this results in 100% CPU usage with timeouts lower than 1000 ms.
Couldn’t find bugzilla so I posted it here.

Best regards,
Johan



------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk



_______________________________________________
Jsonrpc-cpp-devel mailing list
Jso...@li...<mailto:Jso...@li...>
https://lists.sourceforge.net/lists/listinfo/jsonrpc-cpp-devel

Hi,

IIRC I fix this bug in SVN trunk some month ago.

Regards,
--
Seb

Le 28/08/2013 16:36, Johan Gielens a écrit :
>
> Hello,
>
> I found a bug in jsonrpc_tcpserver.cpp on line 139:
>
> tv.tv_usec = (ms % 1000 ) / 1000;
>
> should be:
>
> tv.tv_usec = (ms % 1000 ) * 1000;
>
> If the WaitMessage function is used in a loop, this results in 100% 
> CPU usage with timeouts lower than 1000 ms.
>
> Couldn't find bugzilla so I posted it here.
>
> Best regards,
> Johan
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Jsonrpc-cpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsonrpc-cpp-devel

Hello,

I found a bug in jsonrpc_tcpserver.cpp on line 139:

tv.tv_usec = (ms % 1000 ) / 1000;
should be:
tv.tv_usec = (ms % 1000 ) * 1000;

If the WaitMessage function is used in a loop, this results in 100% CPU usage with timeouts lower than 1000 ms.
Couldn't find bugzilla so I posted it here.

Best regards,
Johan

I am loading a shared library dynamically using dlopen. Now i
want to invoke a function in that library using json rpc. How can i do
that? Can you please help me to solve this problem?

-- 
Anoop.

You need to use dlsym()
Man page: http://linux.die.net/man/3/dlsym

As you can see - you need to know the symbol name (function name)

On Wed, Mar 13, 2013 at 7:01 PM, Anoop Ravi <ano...@gm...> wrote:
> Hi,
>
>          I humbly request your help. It may be simple for you.but i am
> struggling with that. Please help me to tackle this situation.
>
>         I am loading a shared library dynamically using dlopen. Now i
> want to invoke a function in that library using json rpc. How can i do
> that? Can you please help me to solve this problem?
>
>         Hope to hear from you as soon as possible
>
> --
> Anoop.
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Jsonrpc-cpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsonrpc-cpp-devel

Hi,

         I humbly request your help. It may be simple for you.but i am
struggling with that. Please help me to tackle this situation.

        I am loading a shared library dynamically using dlopen. Now i
want to invoke a function in that library using json rpc. How can i do
that? Can you please help me to solve this problem?

        Hope to hear from you as soon as possible

-- 
Anoop.

Hi,

According to the wikipedia page (http://en.wikipedia.org/wiki/JSON-RPC)
notifications are indeed a part of the specification.
This is also backed by the actual specification, although more reading is
required (http://www.jsonrpc.org/specification#notification):

>From Section 2:

"All member names exchanged between the Client and the Server that are
considered for matching of any kind should be considered to be
case-sensitive. The terms function, method, and procedure can be assumed to
be interchangeable.

The Client is defined as the origin of Request objects and the handler of
Response objects.
The Server is defined as the origin of Response objects and the handler of
Request objects.

One implementation of this specification could easily fill both of those
roles, even at the same time, to other different clients or the same
client. This specification does not address that layer of complexity."

And finnaly from section 4.1:
"A Notification is a Request object without an "id" member. A Request
object that is a Notification signifies the Client's lack of interest in
the corresponding Response object, and as such no Response object needs to
be returned to the client. The Server MUST NOT reply to a Notification,
including those that are within a batch request.

Notifications are not confirmable by definition, since they do not have a
Response object to be returned. As such, the Client would not be aware of
any errors (like e.g. "Invalid params.","Internal error.")."

I have implemented this with jsonrpc-cpp, but I don't remember exactly what
I changed (if anything).
If you're interested I could try to make a nice patch for it?

// Fredrik


On Sat, Dec 22, 2012 at 9:21 AM, Sebastien Vincent <
seb...@cp...> wrote:

> Hi Andrey,
>
> Do this feature is part of the official JSON-RPC specification ?
>
> Anyway this feature seems interresting to me but currently I am a bit
> busy. I will be more than happy to review patches.
>
> Regards,
> --
> Seb
>
> Le 19/12/2012 21:17, Andrey Gursky a écrit :
> > Dear Sebastien,
> >
> > the so called "server-side" notifications are described here:
> > http://wiki.xbmc.org/index.php?title=JSON-RPC_API#Notifications.
> >
> > What do you think about such feature? Or is there any good another
> > design pattern that could avoid polling from clients.
> >
> > Regards,
> > Andrey
> >
> >
> ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > _______________________________________________
> > Jsonrpc-cpp-devel mailing list
> > Jso...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsonrpc-cpp-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Jsonrpc-cpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsonrpc-cpp-devel
>

Hi Andrey,

Do this feature is part of the official JSON-RPC specification ?

Anyway this feature seems interresting to me but currently I am a bit 
busy. I will be more than happy to review patches.

Regards,
--
Seb

Le 19/12/2012 21:17, Andrey Gursky a écrit :
> Dear Sebastien,
>
> the so called "server-side" notifications are described here:
> http://wiki.xbmc.org/index.php?title=JSON-RPC_API#Notifications.
>
> What do you think about such feature? Or is there any good another
> design pattern that could avoid polling from clients.
>
> Regards,
> Andrey
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Jsonrpc-cpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsonrpc-cpp-devel
>

Dear Sebastien,

the so called "server-side" notifications are described here:
http://wiki.xbmc.org/index.php?title=JSON-RPC_API#Notifications.

What do you think about such feature? Or is there any good another
design pattern that could avoid polling from clients.

Regards,
Andrey

Hi all,

Due to sourceforge changes, the SVN repository has moved to this place: 
svn://svn.code.sf.net/p/jsonrpc-cpp/code/trunk.

Regards,
--
Seb

Hi,

I'm looking to use jsonrcp-cpp over websockets. The websocket parts is
solved by websocketpp,
but I now face a "problem" with jsonrcp-cpp and was wondering what you
would think would be the
best solution for me.

What I'm doing is a server where a server can login, and is logged in until
socket disconnect.
Upon connection an event is to be fired on the server, possibly sending
multiple notification messages
to the client.
So my implementation is a two-way rpc - not just client -> server with
responses.

I have the client-side all worked out - it is after all much simpler since
there is only one server.

My problem is that the CallbackMethod does not know from where a message
came.
So I need to pass this information to the CallbackMethid in some manner.

I have two possible suggestions, I've considered both and am looking for
something which might
be possible to incorporate in the mainline release, and not just a for-me
hack...
1. Have the client send the username with each request. The entire request
is passed to the callback, so a centralized list of all logged in users
would allow the CallbackMethod to make a lookup on the connection to send
messages.
2. Add templates to jsonrpc-cpp. Make the callback function take three
arguments, one of which is a generic class which would be an application
specific connection id container.

Any suggestions?

Thanks
// Fredrik

Hello,

I'm making a tool to remotely control a HTPC that runs XBMC. I want to
support both TCP and HTTP, but I noticed that for the derived clients,
TcpClient and HttpClient, the [ssize_t Send(const std::string& data)]
function is local to each derived class, and is not purely virtual from the
base Client class. I came into problems when I tried to construct the
clients from the base class depending on arguments supplied at runtime. For
example:

Json::Rpc::Client* client;
if(Args.getProto() == "tcp")
  {
    client = new Json::Rpc::TcpClient(Args.getHost(), Args.getPort());
  } else if(Args.getProto() == "http")
  {
    client = new Json::Rpc::HttpClient(Args.getHost(), Args.getPort());
  }
... builds queryStr ...
client->Send(queryStr);  <--- This causes error: 'class Json::Rpc::Client'
has no member named 'Send'

I'm new to Jsonrpc-cpp, so maybe I'm having a brain fart and I'm not seeing
why Send(const std::string& data) is not purely virtual. Anyone else ran
into problems like this? I haven't had the time to see if I can patch up
the library and make it work, I may do that later this weekend.

Regards,
Chris

Hi,

Fixed in SVN revision 64.

Best regards,
--
Seb

Le 27/03/2012 12:47, seb...@cp... a écrit :
> Hi,
>
> Thank you. You are right, effectively TCP sockets are not closed prior 
> being removed from the list. This will be fixed asap when I go back home.
>
> Best regards,
> --
> Seb
>
> Envoyé depuis mon HTC
>
> ----- Reply message -----
> De : "PEI Normandie" <pei...@gm...>
> Pour : <jso...@li...>
> Objet : [Jsonrpc-cpp-devel] Bug report : Accept connexions
> Date : mar., mars 27, 2012 03:29
>
>
> Hi all,
>
> Currently working on JSON RPC CPP, TCP Server, I have many concurrent 
> connexions and many many many calls ...
>
> After hundreds of calls, the server took 100% CPU load. The select 
> method did not wait. In fact, the call was registered, but the accept 
> method returned false !
>
> After looking at ERRNO, I found out that I had a too many files opened.
>
> *The solution was simple :*
>
> Close the client file descriptor after the call to be treated.
>
> In current (non threaded) version 0.4 : File src/json_tcpserver.cpp 
> line 159, close the m_client before removing them from the std::list
>
> I think it is the same for UDP servers ?
>
> For the moment, the file descriptors are never closed .... no a good 
> idea :)
>
>
> Hope that helps !
>
> Médéric Salles
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
> _______________________________________________
> Jsonrpc-cpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsonrpc-cpp-devel

Hi,

Thank you. You are right, effectively TCP sockets are not closed prior being removed from the list. This will be fixed asap when I go back home.

Best regards,
--
Seb

Envoyé depuis mon HTC

----- Reply message -----
De : "PEI Normandie" <pei...@gm...>
Pour : <jso...@li...>
Objet : [Jsonrpc-cpp-devel] Bug report : Accept connexions
Date : mar., mars 27, 2012 03:29
Hi all,
Currently working on JSON RPC CPP, TCP Server, I have many concurrent connexions and many many many calls ...
After hundreds of calls, the server took 100% CPU load. The select method did not wait. In fact, the call was registered, but the accept method returned false !

After looking at ERRNO, I found out that I had a too many files opened.
The solution was simple :
Close the client file descriptor after the call to be treated.

In current (non threaded) version 0.4 : File src/json_tcpserver.cpp line 159, close the m_client before removing them from the std::list

I think it is the same for UDP servers ?
For the moment, the file descriptors are never closed .... no a good idea :)

Hope that helps !

Médéric Salles

Hi all,

Currently working on JSON RPC CPP, TCP Server, I have many concurrent
connexions and many many many calls ...

After hundreds of calls, the server took 100% CPU load. The select method
did not wait. In fact, the call was registered, but the accept method
returned false !

After looking at ERRNO, I found out that I had a too many files opened.

*The solution was simple :*

Close the client file descriptor after the call to be treated.

In current (non threaded) version 0.4 : File src/json_tcpserver.cpp line
159, close the m_client before removing them from the std::list

I think it is the same for UDP servers ?

For the moment, the file descriptors are never closed .... no a good idea :)


Hope that helps !

Médéric Salles

Hi all,

JsonRpc-Cpp 0.4 has been released. Feel free to download and test it.

In this release, we have a brand new JSON-RPC HTTP client based on 
libcurl (contribution from Brian Panneton).

Best regards,
--
Sebastien Vincent

Hi,

Le 15/02/2012 12:38, Ditwin - Contact a écrit :
>
>
>      Just for information, d you have reports and statistics about that ?
>
>
>
> I have two implementations of my website. The first uses Symfony, the 
> second is implemented in PHP, and uses a webservice written with JSON 
> RPC CPP.
>
> I used Apache Benchmark (ab) to compare the two versions. The second 
> version is really faster with about 100 calls. But with a more
>

OK.

>
>         So, make the Recv function to create his own thread, run it
>         and closes the socket.
>
>
>      Do you mean, create one thread per new request ?
>
>
> Yes. But it could be possible to create a set of initial thread when 
> the server starts ? This could be more effective this way, rather than 
> creating one thread, process the method, destroy the thread ... Create 
> a new new and so on.
>
>

The right way would be to have a thread pool and a set of method to 
increase/decrease number of threads.

>
>     The mutex is sometime necessary... it depends if you have objects
>     you would like to share between threads.
>
>
> Ok, I don't need to share objects between thread, because each method 
> create his own objects depending on the requests.

OK.


Regards,
--
Seb