• Questions about JSON rpc service

    By F. Kranenburg 1 decade ago

    We have implemented the JSON rpc service succesfully in our Xpages application. This works fine and does not generate any errors. The next step for us is stress-testing the application. We use 'IBM rational performance tester' for this.

    After testing a while with 50 users the application slowly produces some errors. If you take a look at these screenshots you will see the JSONrpc services generating bad requests. Somehow the JSON request is 'mixed' with the next request.

    I'm not sure you can help me with this, but maybe you have an idea is you look at the screenshots.

     

    bad request 1

     

    bad request 2

    • Hum that looks like a core issue

      By Philippe Riand 1 decade ago

      I will pass this on.

      • looking forward to your response

        By F. Kranenburg 1 decade ago

        When using alternatives like dojo.xhrGet or XSP._partialRefresh calls we are getting HTTP errors when stress testing. This is especially problematic when the HTTP task must be restarted, because it 'waits until all sessions are finished'. This takes infinite time, so a server reboot is the only option to restart the HTTP task. This is not really an option for our customers. I have attached a screenshot of the waiting sessions (nothing to do with the Extension Library)

        The jsonRPCservice does not have this problem and we are very happy about that.

        We really hope this problem can be fixed, if you need more information please contact me at ferry.kranenburg -at- changetocomm.nl

         

    • Questions about JSON rpc service

      By Mike Kerrigan 1 decade ago

      It appears from the symptoms that there are malformed http requests over an http persistant connction.  One cause of this is that the previous request to the server was malformed with regard to the content-length header not matching the number of bytes sent,  a simple example would be the client set the content-length to 10 bytes but 11 bytes were sent, the extra byte will now be part of the next http request and could throw off the parsing of the next request and cause the server to return a bad request error.

      Couple of things to help isolate the issue.

      1. For a test disable http persistant connections on the server.  Setting is in the http tab.  After disabling persistant connections see if the problem still occurs.  If problem does not occur then it is likely a malformed request with extra data, if it still occurs, then it will be necessary to get wire traces of what is going on to understand the issue better.

      2. With regard to the http messages "waiting for session", taking an NSD at the time will help idenify what code is executing that is hanging the thread. 

      It may be necessary to raise a PMR for this because it appears it will take additional investigation to find the root cause.

      • Thanks for helping,but..

        By F. Kranenburg 1 decade ago

        Mike,

        I have disable the HTTP Persistent connections on the test server. It does not solve the malformed request errors. It is only happening when we use the xe:jsonRPCservice from the extension library. Our jsonRPCservice scripts always return 'html' in it's response.

        How should we set-up a wire trace to the server? Thanks again for helping us out.

    • Problem solved

      By F. Kranenburg 1 decade ago

      I'm not sure why the request was malformed but it turns out, our test user 36 was unable to login due a password problem. The application didn't allow anonymous access.

      Because of this, the 'bad request' error was added anonymously to the domino http log.

      Somehow the jsonRPCservice respond to an anonymous request. Maybe that is a bug but I'm not sure.