I use a DevExpress XtraScheduler control to display appointments for many years. In the event CustomDrawAppointment (which is called for every visible appointment) we sometimes have to go to our database with DataAbstract remoteDataAdapter to get a maximum of 4 lines in certain cases. This has always worked just fine before version .1543. We had to update to a later version and now we get a lot of timeouts if the call for the extra info is made more then one time in the event.
We make use of a SuperTcpIPClientChannel en ServerChannel for a very long time.
This is the error message with stack trace:
2023-04-26 15:45:39.6009|ERROR|Adire.DataProxy.DataService|(PlanningControleDataTable_FK_Planning) |System.Exception: Timeout waiting for a response
bij RemObjects.SDK.IpSuperTcpClientChannel.IntDispatch(Stream request, IMessage response) in c:\CI\b\rofx\937\RemObjects SDK for .NET\Source\RemObjects.SDK\ClientChannels\IpSuperTcpClientChannel.cs:regel 710
bij RemObjects.SDK.ClientChannel.Dispatch(IMessage message) in c:\CI\b\rofx\937\RemObjects SDK for .NET\Source\RemObjects.SDK\ClientChannels\ClientChannel.cs:regel 325
bij RemObjects.SDK.DynamicRequest.InternalMakeRequest() in c:\CI\b\rofx\937\RemObjects SDK for .NET\Source\RemObjects.SDK\RemoteService\DynamicRequest.cs:regel 182
bij RemObjects.DataAbstract.RemoteDataAdapter.SendFillRequest(DataSet dataset, String[] tableNames, TableRequestInfo[] tableRequests, WhereExpression[] whereClauses, Boolean applySchema, IList`1 tablesThatNeedSchema) in c:\CI\b\rofx\937\Data Abstract for .NET\Source\RemObjects.DataAbstract\DataAdapters\RemoteDataAdapter.pas:regel 494
bij RemObjects.DataAbstract.DataAdapter.InternalFill(DataSet dataset, String[] tableNames, TableRequestInfo[] tableRequestInfo, WhereExpression[] whereClauses, Boolean applySchema) in c:\CI\b\rofx\937\Data Abstract for .NET\Source\RemObjects.DataAbstract\DataAdapters\DataAdapter.pas:regel 286
bij RemObjects.DataAbstract.DataAdapter.Fill(DataSet dataset, String[] tableNames, TableRequestInfo[] tableRequestInfo) in c:\CI\b\rofx\937\Data Abstract for .NET\Source\RemObjects.DataAbstract\DataAdapters\DataAdapter.pas:regel 364
I’ve already tried to make some changes to make use of a HttpServerChannel en ClientChannel and then it seems to work without timeouts. Are there problems with the SuperTcpIP channels? Is something changed that I don’t know about?
No exceptions are raised server-side… I have no idea what’s going.
I’ve changed my code already so that a RODL function is used to just return a count of the maximum 4 rows out of a database table. After some time (multiple calls made) the same timeout error is thrown:
2023-04-28 09:12:29.8809|ERROR|Adire.DataProxy.DataService|(GetCountPlanningControlesByPlanningPrimkey): Fout bij ophalen aantal planningcontroles
|System.Exception: Timeout waiting for a response
bij RemObjects.SDK.IpSuperTcpClientChannel.IntDispatch(Stream request, IMessage response)
bij RemObjects.SDK.ClientChannel.Dispatch(IMessage message)
bij Adire.Server.AdireServerService_Proxy.GetCountPlanningControlesByPlanningPrimkey(Int32 plnPrimkey) in C:\Dirmacom Projects\XLent Planning\Source\AdireServer\AdireServerLibrary_Intf.cs:regel 2794
Client side code:
public static int GetCountPlanningControlesByPlanningPrimkey(int plnPrimkey)
{
try
{
IAdireServerService _service = CoAdireServerService.Create(_instance.binMessage, _instance.MyClientChannel);
return _service.GetCountPlanningControlesByPlanningPrimkey(plnPrimkey);
}
catch (Exception ex)
{
LogException($"({nameof(GetCountPlanningControlesByPlanningPrimkey)}): Fout bij ophalen aantal planningcontroles\n", ex);
throw;
}
}
Some extra info (but I think you already know because of the log in previous message), but the ‘hang’ happens on the clientChannel.Dispatch(___localMessage):
When I step over the breakpoint at ClientChannel.Dispatch here, the breakpoint serverside isn’t hit, so it’s like there’s a kink between client and server… I’m absolutely not an expert in this, so I hope you know what’s going on .
Which channel is the best then for a ‘old-school’ client-server application with lots of clients requesting sometimes big chunks of data from one server?
The TCP Channel uses a lightweight protocol over raw TCP, introducing basically zero traffic overhead on top of the transmitted message data.
HTTP channel can work through firewall or/and with proxy servers.
If you don’t use server-side events that should be delivered asap to clients, plain channels are good choice.
I’ve changed the channels to normal TCP Channels and like with the normal HTTP channel, I don’t have the timeout problem anymore. So it has something to do with the superChannel.
I have the feeling the normal TCP channel is a bit slower. Am I right, or is this a problem in my head ?