RaiseControlAddInEvent Multithreading

Arne_Rosenfeldt

Hello!

Reading "Installing the tree tiers on three computers" I thought that all tiers run in parallel.
But at the moment my control (based on StringControlAddInBase) on the client computer is blocked by the service tier.
Thus for some month now I searched the web and though about implementing the:
IEventControlAddInDefinition
with its
ControlAddIn Event
.
Which I then plan to beginInvoke.

On construction I would start a new thread and in this thread I would construct a new Windows Forms Control.
The constructor takes no parent handle. Thus I guess windows.forms somehow knows the RTC handle.

I would implement the:
IWinFormsControlAddIn
and the property
Control
would return the Control from that other thread.

My questions:
Is this worth the trouble?
Has anyone tried it?
Would it run in NAV 2013?
Today I thought of this:
Converting the control into a usual window and call it from a CodeUnit. At least in this case there is official documentation about sync and async events. This would be for users who prefer a full screen mode of that control over an RTC page with all the bells and whistles. As already the AddIn does not run on the WebClient this would not impose new constrains.

Greetings!

Arne Rosenfeldt

PS:
I also have the feelling that FindSet and CalcField are blocked by the SQL Server. Or is this just in the Classic Client (where I can look at this using Client monitor)? Is the NAV 2013 Query Object better in this respect? Does anyone plan a QueryObject emulator for older NAV versions? After NAV has generated the SQL code for two flowFields, my C/AL Code should merge them into one SQL command for speed and because ADO allows async excution! I have no personal access to the computer and the flowField definition. I do not even know which NAV version it runs on. Is there something like ISSERVICETIER for NAV2013? What happens on import?

kine

There is too much questions in one post. Just few answers to may be unimportant questions:

Is there something like ISSERVICETIER for NAV2013? What happens on import?

Why? Everything is running on 3tier architecture now, it means everything is ISSERVICETIER=true.

I also have the feelling that FindSet and CalcField are blocked by the SQL Server

What do you mean with this? What you mean with "are blocked"?


In generally- NAV client is single-threaded, thus processing only one event at the time. I expect that the RTC will not be able to proces two simultaneous events from the addin. You will need to implement e.g. some semaphore or the events are waiting in queue to be processed.

Arne_Rosenfeldt

Hello kine!

I use ISSERVICETIER to decide if I call the form or the page.
Now I need ISNAV2013 to decide if I call a query object or an ADO object (OLE automation on Service Tier).

>What do you mean with this? What you mean with "are blocked"?
The client waits for the service tier to finish some stuff.
And while it waits, it blocks the user from scrolling, and animations from playing ...
Lock block.

>In generally- NAV client is single-threaded,
It is okay for me that the client is single threaded. The client is fast.
But the service tier is another process on another computer, thus it cannot be in the same thread as the client.
I have the feeling that this multithreading only benefits systems with many users on it.
But our customer complains about the performance of NAV for a single user.

I hope that the client does not process any event. It should just forward it to the ServiceTier. And I plan to send only one event at a time. I just want my control to stay alive. And I cannot belive that the client can only accept one event at a time. It is a windows.forms application. Thus it has a message loop. With OLE this loop would be used.

Thanks
Arne

kine

I am starting to understand... :-)

Regarding ISSERVICETIER - as I wrote, you do not need it. At first, automations are not supported anymore in NAV 2013, only .net interop could be used. Everything is on the new code stack, thus you have simple choise here... ;-)

Regarding threading - in NAV 2013 some things are asynchronous, but I do not know how far this asynchronousness is going (e.g. charts are loaded asynchronously, thus not blocking the client). I will try to dig more into this.

Of course, NAV server is multithreaded, but I thing this is clear. But, not everything is executed on the server, e.g. client side .net interop is processed on the client (and some addin things). But this is only exception.

Arne_Rosenfeldt

Hello Kine!

Regarding the AddIn it struck me that I could implement the two interfaces in two classes.
On class runs in the windowsForms thread of the RTC and implements the windowsForms interface.
The other class implements the AddInBase class and runs in it own thread.
I guess I have to try it out myself. On a freshly backed up machine without network. And then look for
"Control <control name> accessed from a thread other than the thread it was created on."

It seems I have a problem to stick to the topic ...
In my current project there are places where I need to start windows outside the RTC and then there is this windows scripting host file coping stuff on the client. Fortunately I have no performance complaints at that place.

In the past I did read a lot about multi-player network games and I use a web-browser.
In both cases the client runs fast on my Notebook (60 fps): I can scroll, switch tabs, turn around.
In both cases the server is slow: The Position of the other player is not up to date, MSDN website needs seconds to load in a background tab.
As a developer/adim/user I can clearly see where the performance problem lies.
On a modern system I except every program to behave like this. I hate white-out (as it looks in Win7) and modal windows.
Now with the AddInControl Event we constantly have the problem to locate (performance-) problems [AddIn|CAL].

The most performance problems seem to lie on the ServiceTier.
Generally going to newer Versions of Nav improved performance drastically.
I got complains about performance using the ClassicClient on SqlServer.
I tested on NAV 2009SP2 RTC and the code ran twice as fast. I have heard that most customers use this version.
I believe NAV 2013 will be even faster, but I have not yet installed it on my development system.
I want code which improves performance on the classic client, runs really fast on NAV2009SP2 and is compatible with NAV2013.

Being used to assembler, C++, Java, C#, I guess I expect too much from C/AL. In a language where I cannot implement an Interface, declare generics ... how do I dare to expect explicit multi-threading. I mean the SQL server does wonders in pattern recognition when it compiles SQL-scripts to execution plans. Same goes for C++ and C# compilers. But these are main-stream programs. I have not seen a hint that the C/AL is that advanced. And in C/AL the compiler would have to do so much more because it its a RapidDevelopment language and as a developer I am not allowed to tune things, give explicit hints. I always laughed about the pascal guys who constantly needed to build modules in assembler whereas in C++ I can gradually move from clean object oriented C++ to a more C like style to get the same speed as the pascal guys.

To be compatible with NAV2013 and to speed things up on NAV2009SP2 I want to move to ADO.NET. I want to use StringBuilder to build queries longer than 1024 characters. To feed StringBuilder to the commandText property I have to use ToString. And here comes NAV, which reinterprets "ToString" as "ToText". Whoever thought that one out? I like the RTC (its looks, the tailor stuff for the user, the improved OnValidate). I like the declarative nature of flowfields and think that VSIFT is ideally suited for the typical NAV applications. But how can I use these both without that ugly C/AL getting in my way? And there is one thing with the query objects, I do not understand. A query typically replaces a procedure. Multiple procedures are grouped into on unit. Why did they not introduce QueryUnits? Then I could use a 1:1 number relation between old CodeUnit and the QueryUnit I derived from it.

Greetings
Arne Rosenfeldt

kine

Arne, the problem is this: C/AL is not the tool you need for doing what you are describing. You are trying to use scalpel instead knife to cut the bread. You cannot expect multhithreading, full control over the process, etc. etc. from this business logic focused language. Developing multiplayer game in it will lead to problems. In contrast - I am trying to create some WPF application as replacement for some application I developed in Classic NAV. In NAV it took me 3 days. The WPF application already eated more than two weeks and I am spending days just with simple functionalities (of course, I am learning myself the WPF, but even when I am searching for solutions of simple problems, the implementation of the solution is very comples). E.g. Lookup - in NAV just settings correct table relations. In WPF - all the bindings, converters, validators... :-) I hope you see the point...

I will never try to solve some problems in C/AL, and I will rather create assembly (ActiveX library for classic) to do it outside. Same as I will not try to develop something I can create in NAV quickly in C# instead...

henrikm

It does seem like a very intereting thing you are implementing.

Note sure this helps - but with regards to multithreading... you have to handle it all and you can only call the framework on the UI thread (that is what it expects). Also there can only be one call going from the client to the server and the client will wait for that call to return from the server before you are allowed to call the framework again. (You would see exceptions if you do not do that).

For the C/AL you run on the Service Tier (NCL) you can use background processes - however you do not have a means to - when done to push this information to the client. You basically have to have the client call the server and when it does that you can send the information back.

As the client is single threaded so is C/AL (except for the session concept, where you have to use the db as semaphore).

I do not think you can easily obtain what you are trying to - perhaps you can sketch the overall design/architecture of what you are implementing?

/henrik

Arne_Rosenfeldt

You are right, implementation in NAV is faster. But there is already a correct implementation, which is used by customers, and which users complain is too slow. I spend the last two weeks converting C/AL to SQL. The program got faster about a factor of 10(at least on my test system). I will probably try to cut out the service tier and call SQL procedures from C# and let NAV compile the rest of the C/AL to C#. And then I wait for the first complain that a change to a flowfield definition is not reflected by my SQL code.