Connection through thread

Kobe · 2013-07-01 19:05:39

Hello,

I need to make the connection between client and server happens through a thread, besides the main application thread, because sometimes the connection may take longer than normal and the application freezes for a few seconds waiting for the end of the connection.

What better way to do this? Is there another way to solve this freezing?

Thanks.

ab · 2013-07-01 19:49:08

You can use several client connections, one per per thread.

But you can also use a background thread on the server side, if some process takes time.

Kobe · 2013-07-01 20:57:30

The thread that I'm talking about would be on the client side, can I use a thread to connect?

ab · 2013-07-02 04:30:13

Yes, with a given client instance.

Kobe · 2013-07-02 11:40:57

OK, how can I make to force the client to create a new thread, on the client side, to connect to the server?

Last edited by Kobe (2013-07-02 11:41:30)

ab · 2013-07-02 13:56:08

There is no way of doing it in the current client implementation.

You have to create your own TThread sub class, the use a dedicated client instance in its Execute method.

Kobe · 2013-07-02 14:17:36

Would the new class should work over the TSQLHttpClient class?

Do you think a implementation like this can be good to the mORMot project, working as a option to the current implementation?

Last edited by Kobe (2013-07-02 14:19:12)

ab · 2013-07-02 17:22:59

You mean having an asynchronous mode from the main thread, or using a dedicated thread for background process?

Kobe · 2013-07-02 17:34:21

Yes
Does that make any sense for the mORMot project?

Last edited by Kobe (2013-07-02 17:34:53)

ab · 2013-07-02 19:42:51

This is just a way of making the client more fluid.

Kobe · 2013-07-02 20:32:09

Wich is better to solve the freezing problem: the asynchronous mode or the edicated thread for background process?

How can I help you on this development? I'm not as wise as you're on Delphi development.

ab · 2013-07-02 20:34:00

Asynchronous mode is very tempting...

Kobe · 2013-07-02 22:18:03

How would work this Asynchronous mode?

ab · 2013-07-03 09:13:51

Either with an overriden TSQLRestClient.URI() which will allow calling a custom property during waiting (e.g. for Application.ProcessMessage), and use a background thread during the blocking communication.

Or with a dedicated "tasker" - new TTask class which may be also needed for implement future event-driven programming - http://blog.synopse.info/post/2012/09/0 … laboration

KJames · 2013-07-03 12:01:41

ab wrote:

...and use a background thread during the blocking communication.

What would be the function of this background thread?

ab · 2013-07-03 13:09:25

KJames wrote:

What would be the function of this background thread?

... doing the blocking communication itself, without blocking the main thread, so the main UI.

You have several options, e.g.
- the microsoft Task class - http://msdn.microsoft.com/en-us/library … .task.aspx
- the RemObject asynchronous call - http://wiki.remobjects.com/wiki/Asynchr … K_(Delphi)
- Or just allow to run an "idle" method e.g. to run Application.ProcessMessage, display a popup window if times is noticeable, and/or allow request cancel.

Perhaps the 3rd could be OK..

Kobe · 2013-07-03 14:33:31

I believe the 2nd may be the better option, and can solve this feature request: http://synopse.info/fossil/info/68337ae98a

ab · 2013-07-03 15:22:56

Kobe wrote:

I believe the 2nd may be the better option, and can solve this feature request: http://synopse.info/fossil/info/68337ae98a

But I'm still not convinced about the "exploded" new interface in such case.

If the purpose is only to let the UI interact properly as expected, the 3rd solution is clean & enough.
This is what I will do in the short term - prepared by http://synopse.info/fossil/info/a5ae673869 latest commit, in fact.

Then event-driven publish/subscribe methods will probably a better option than this RemObjects' "exploded" interfaces.

Kobe · 2013-07-03 16:52:28

You are totally right. I was testing and the connection got a little bit faster too, is that related to this change too?

ab · 2013-07-03 17:42:03

Kobe wrote:

I was testing and the connection got a little bit faster too, is that related to this change too?

I do not think so, honestly...

ab · 2013-07-04 13:00:15

Take a look at http://synopse.info/forum/viewtopic.php?pid=8045#p8045

Enjoy!

mORMot Open Source

#1 2013-07-01 19:05:39

Connection through thread

#2 2013-07-01 19:49:08

Re: Connection through thread

#3 2013-07-01 20:57:30

Re: Connection through thread

#4 2013-07-02 04:30:13

Re: Connection through thread

#5 2013-07-02 11:40:57

Re: Connection through thread

#6 2013-07-02 13:56:08

Re: Connection through thread

#7 2013-07-02 14:17:36

Re: Connection through thread

#8 2013-07-02 17:22:59

Re: Connection through thread

#9 2013-07-02 17:34:21

Re: Connection through thread

#10 2013-07-02 19:42:51

Re: Connection through thread

#11 2013-07-02 20:32:09

Re: Connection through thread

#12 2013-07-02 20:34:00

Re: Connection through thread

#13 2013-07-02 22:18:03

Re: Connection through thread

#14 2013-07-03 09:13:51

Re: Connection through thread

#15 2013-07-03 12:01:41

Re: Connection through thread

#16 2013-07-03 13:09:25

Re: Connection through thread

#17 2013-07-03 14:33:31

Re: Connection through thread

#18 2013-07-03 15:22:56

Re: Connection through thread

#19 2013-07-03 16:52:28

Re: Connection through thread

#20 2013-07-03 17:42:03

Re: Connection through thread

#21 2013-07-04 13:00:15

Re: Connection through thread

Board footer