Callbacks blocking new requests

Remoting SDK
22

Not sure to be honest, my function on the server will process a lot of records and we send callback to every record, very fast…

the main point is i dont belive the callback should affect the main connection .

In this particular case, we dont need this much callback, on the other hand we have a lot of clients connect and callback will happen all the time, if this will affect the main connection, i think is a problem

23

Hi,

do you mean here client channel components:

  • TROSynapseSuperTCPChannel
  • TROIndySuperTCPChannel
  • TROSuperTcpChannel

?

24
  • TROSynapseSuperTCPChannel
  • TROIndySuperTCPChannel
  • TROSuperTcpChannel

components used to comunicate server ↔ client

the error message is on the server side, when the client try to talk to the server…

thats the question? im sorry im starting to be a little lost here…

25

we did change the server ↔ olympia too, but cant remeber if u need i can retest again…

26

Hi,

I mean, SuperTcp channel that is assigned to TROOlympiaSessionManager.Channel on server-side.

Have you tried to change it to other one?

27

we did, i need to test again to capture de message, but i had the same problem

28

Hi,

can you try to reduce some events.
will it improve stability of server?

29

yes, it will improve, but like i said i dont think this should be releated, i do have a lot of callbacks, and we have a big client (110+ clients connected), this will generate a lot of callbacks.

I did try to change to olympia in this particular client, but the speed was abysmal and i had to rollback, i think the callback is releated to the performace issue

30

Hi,

Can you review possibility to split your events to Olympia- and InMemory- EventRepository, pls?

Say, more critical events should use Olympia and other ones should use InMemory.

How it can be done: non-critical events should use InMemoryEventRepository and another service and/or server component. it should decrease usage of olympia channel and improve stability of server. also it can use plain tcp/http server channel for such events. in this case clients will ask server for non-critical events every X seconds and receive all incoming events in one request. Of course, client-side should use 2 event receiver components - one for critical events and one for non-critical ones.

Note: in your current implementation, each event is sent via SuperTcp channel only it is appeared on server-side.

31

yes i thought about doing that, i can give a try