RTC Forums
May 06, 2024, 02:37:43 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: TRtcRouter and multiple reqeusts  (Read 3248 times)
Dany
RTC License++
*****
Posts: 69


« on: August 26, 2015, 02:26:02 PM »

I have several servers behind a router. The server with the routerprovider (datamodule with TRtcDataRouter components) serves some requests, mainly session-stuff and routes the rest. The routerprovider has the lowest CheckOrder value for it's ServerLink.

Some of the servers "behind" the router needs to get small tidbits of cached data from some one of the servers. Rather than coding tables of the different servers addresses and ports for each one (the datamodules can be compiled into different services too so that messes that approach up even more), i use the router to route even the client requests made by the servers themselves. This has worked fine, i think.

Today i made such a client request from a server (lets call it the settings server). The thing with this request is that it goes to the router and then back to the settings server /itself/ where another datamodule with another TRtcDataProvider serves the request. This did not work because the client request gets stuck at the router! After a while of hair-pulling i copied the TRtcDataRouter component (and the TRtcDataRequest and TRtcHttpClient that comes with it) and moved that particular request to be routed by this new TRtcDataRouter component. And now things works as they should again!

All TRtcHttpServer components are multithreaded. The router provider has MultiThread and HyperThreaded checked fo all components. I was under the impression that using a fully multithreaded server the requests would all be served inside their own thread. So i can not understand why this particular request (though i know what is different with it of course) get stuck. Interesting is that the client request fired by the event handler for the TRtcDataProvider reaches the router immediately but reaches (back to) the settings server more or less exactly one minute after it came to the router.

What i have in the router provider is repetitions of the following setup for each potential target server:

Code:
procedure TRouting_Provider.RtcDataRouter1CheckRequestI(Sender: TRtcDataServer);
begin
    if (Sender.Request.FilePath.Equal(0, 'COMMAND1') or
        Sender.Request.FilePath.Equal(0, 'COMMAND2)) then
      Sender.Accept;
end;

procedure TRouting_Provider.RtcDataRouter1PostNewRequestI(
  Sender: TRtcDataServer; var DataRequest: TRtcDataRequest;
  var AddToQueue: Integer; var MoveToBottom: Boolean);
begin
  if FClosing then exit;
  DataRequest := RtcDataRequest1;
end;

procedure TRouting_Provider.RtcDataRouter1RequestReceivedI(
  Sender: TRtcDataServer; Content: TRtcRouterContentBody);
begin
  RequestReceived(Sender, Content);
end;

Where "RequestReceived" changes some header info (something like Sender.Request.Value['somesessioninfo'] := 'info'Wink it does NOT touch the Content parameter.

Each TRtcDataRouter component has a TRtcDataRequest component (designtime) with "HyperThreading" checked. Each TRtcDataRequest component has a TRtcHttpClient component (designtime) with "MultiThreaded" set to true.

Either i have done something very wrong with the way i use the router component or i have missed something basic with this whole thing. I know about the demos (those where used). Maybe the router is waiting for the initial request to finish in these cases? But in that case how can the router serve multiple users? I am at a loss here and would appreciate any pointers or insights.

Regards,

/Dany
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #1 on: August 26, 2015, 02:57:13 PM »

In order for the Router to "route" requests to one Server, one TRtcHttpClient with one TRtcDataRequest component is required for one active connection. If you use only one TRtcHttpClient component and send a request to the Router, but do NOT create additional instances of TRtcHttpClient and TRtcDataRequest components for handling additional requests at the same time, then the Router won't be able to accept new requests until a complete request and response has been received and forwarded for the 1st request. This is why using a separate TRtcDataRouter with a separate TRtcHttpClient and TRtcDataRequest instance has fixed your problem.

Normally, instead of using a single TRtcHttpClient and TRtcDataRequest component per TRtcDataRouter (which is what you seem to be doing), you would need to manage a pool of TRtcHttpClient and TRtcDataRequest components and use a separate instance for each new request that has to be posted by the Router, or ... if there are no free instances available and you do not want to grow the pool, force the Client to wait for one of the instances to become available again before the request is posted to the Server. Since you only have one instance of a physical connection and data request component, no matter how you set up the components, you won't be able to handle more than one request at a time.

I hope that makes sense.

PS. The Router Demo Projects have a parameter to define the maximum number of "Outgoing Connectins" (bottom left), which defines the size of the outgoing connection pool (TRtcHttpClient+TRtcDataRequest component sets) to be created and maintained. Leaving this parameter at default (=1), Demo Router Projects will also be able to manage only one physical connection at a time. To handle more, the parameter needs to be increased.

Best Regards,
Danijel Tkalcec
Logged
Dany
RTC License++
*****
Posts: 69


« Reply #2 on: August 26, 2015, 03:05:41 PM »

Yes, it does make sense, i have another router that was build like that (it's adifferent beast though). My mistake is that i confused the multi- and hyper properties of the clients with routing functionality. Now i know exactly what to do in order to make the sofware stable. Thank you very much for prompt and well-written support.

/Dany
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.025 seconds with 16 queries.