TROIpSuperHTTPServer bugs/problems and question

Remoting SDK
1

Hello all,

I’m trying to optimize performance in one of my remoting servers. I read that tROIpSuperHTTPServer has less overhead than tROIndyHTTPServer so I thought I might as well use it.

Now one of our developers reports compatibility problems:

  1. If a SOAP or JSON message type is used and the POST request contains the service name (for example: “POST /SOAP?service=myservice”) then the tROIpSuperHTTPServer returns “Cannot find message dispatcher” wheas the tROIndyHTTPServer works correctly.

This makes tROIpSuperHTTPServer incompatible with Delphi clients that use Delphi’s built-in SOAP routines.

  1. If the JSON message type is used, then tROIpSuperHTTPServer returns responses as “Content-Type: text/html” whereas tROIndyHTTPServer returns “Content-Type: application/json”.

Additionally, I have a question:

How do you control the threading behavior (number of concurrent threads, size of the thread pool) of a remoting server? tROSuperHTTPServer has a property “Threadpool” but I find no matching components to fill the property. I need ~ 25 concurrent threads.

2

Thanks, logged as bugs://80937

3

bugs://80937 got closed with status fixed.

4

Thanks, logged as bugs://80938

5

bugs://80938 got closed with status fixed.

6

Hi,

pls update uROHTTPDispatch.pas as

function TROHTTPDispatcher.CleanPathInfo(const iPath:string):string;
var  i: Integer; //added
begin
  result := iPath;
  i := Pos('?', result); //added
  if i > 0 then Delete(result, i, MaxInt); //added
...

and uROBaseSuperHttpServer.pas as

procedure TQueueItem.SetHeaders(const aName, aValue: String);
begin
  fResponseHeaders.Headers.Values[aName] := aValue; //changed
end;

TROThreadPool is not visual component.
You can set ROServer.ThreadPool.MaxThreads to 25.
overall number of items that can be processed, is calculated as MaxThreads*MaxQueue

7

Thanks for a speedy bugfix!

I’ll report back after testing.

Kind regards,

Arthur

8

Hi Evgeny, the bugfix appears to work, thanks a lot for looking into this so fast! Top service!

My co-worker reported another incompatibility, though. It appears that the WSDL returned by the Soap message type is different between the two server components.

in tROIndyHTTPServer, the returned path is absolute:
…
<wsdl:port name=“databasePort” binding=“tns:databaseBinding”>
<soap:address location=“http://192.168.0.25:30844/SOAP?service=database”/>
</wsdl:port></wsdl:service></wsdl:definitions>

in tROSuperHTTPServer, the returned path is relative and because of this my co-worker’s existing PHP code is no longer working :
…
<wsdl:port name=“databasePort” binding=“tns:databaseBinding”>
<soap:address location="/SOAP?service=database""/>
</wsdl:port></wsdl:service></wsdl:definitions>

Thanks for your attention!

Kind regards,
Arthur

9

can you create a simple testcase that reproduces this case, pls?
you can attach it here or send directly to support@

10

test.rar (33.8 KB)

Testcase attached.

“testProject.dpr” is the SOAP server, it listens on port 8099 and 8100.

You will see that “http://localhost:8099/SOAP” returns a different WSDL as “http://localhost:8100/SOAP”.
The server on port 8099 returns an absolute path under <soap:address location> whereas the server under port 8100 returns a relative path.

11

Thanks, logged as bugs://80985

12

bugs://80985 got closed with status fixed.

13

pls update uROBaseSuperHttpServer.pas as

function TQueueItem.GetLocation: string;
begin
  result := id_http+GetHeaders(id_Host);  //changed
end;