The configurator mechanisms, which provide group development of an application solution, allow a group of developers to make changes to the configuration simultaneously, as each of them completes their part of the work. This procedure for making changes is ensured by the ability to determine the access rights of each developer to modify objects of the application solution:
Configuration storage
The configuration repository is a tool that allows for group development of application solutions. The configuration repository also provides versioning of changes made in the developed configuration. Because of this, using the repository can be very useful for a single developer, because... allows you to document changes made in an application solution and work with versions.
To carry out group development of an application solution, a configuration repository is created on a public network resource and its administrator is appointed:
The administrator creates a list of users who have access to the storage, can view the list of users connected to the storage and release configuration objects from capture:
In order to be able to modify an application solution located in the repository, the developer needs to connect to the repository by specifying a username and password:
Configuration Storage Window
In group development, an application solution is considered as a set of objects that are closed for change. Each user allowed to work with the repository can “capture” for modification an arbitrary number of objects that have not been captured by other users. Each object can only be captured by one user:
Each of the developers connected to the repository edits objects captured in the repository and debug the application solution on their current information base in the same way as in normal mode. After making changes to an application solution object, the developer can place the changed object in a repository so that other users can update the object in their configurations. In this case, the developer can provide the changes made with a text comment:
At any time, you can compare the current configuration with the repository or save the repository as a configuration.
History of the repository
1C:Enterprise Configurator supports maintaining storage history:
Each line of the list displays the next version of the application solution in the repository. Each version can be opened for viewing, loaded instead of the current one, compared with the current one, or saved to a file on disk.
The ability to roll back and delete unnecessary versions published to the repository is supported, as well as the ability to remove the earliest unnecessary versions by trimming down to the desired version.
It is possible to display reports on the storage history, containing information about changes in individual elements of the application solution and the entire application solution as a whole:
The repository version report shows the composition of added or changed objects:
The report on development objects contains information about changes that were made to specific objects of the application solution:
The comments report allows you to analyze the comments that developers use to accompany configuration changes:
Thus, using the repository is also useful for a single developer, because... The repository history allows you to document changes made in the application solution and work with versions.
Working with storage in the configuration window
Functions for working with the repository are available not only from the repository window, but from the configuration window. It, like the storage window, displays the status of configuration objects:
While in the configuration window, the developer can grab objects in the store, undo the grab, put objects in the store, compare an object with an object in the store, and get the history of the store object.
In addition, you can perform a selective comparison, which does not compare entire configurations (new and old versions). Only individual properties of the object of interest or the object itself are compared. A list of properties available for selective comparison is displayed in the context menu.
Working with storage without a connection
Some actions with storage can be performed without a connection. If the current configuration is not connected to the repository, the developer can establish a connection to the repository:
In connection mode, all actions related to viewing storage data, comparing objects and configurations, as well as administering the storage (if you have the appropriate rights) will be available. Only actions related to capturing and placing objects in storage are not available:
Remote work with configuration storage
Starting from version 8.1.11, you can work with the configuration repository using not only a shared network resource, but also a local network connection (using the TCP protocol) and an Internet connection (using the HTTP protocol). In general, developer interaction with the configuration repository might look like this:
The configuration storage can be located on a computer running both Windows and Linux operating systems.
On the Windows operating system, the configuration storage server can be run as an application or installed as a service.
On the Linux operating system, the configuration repository server can be run as a process or as a daemon. Wherein:
- When connecting via TCP, the "client application" interacts with the configuration storage server. That, in turn, interacts directly with the storage.
- When connecting via the HTTP protocol, the "client application" connects to the web server. The web server accesses the repository server, which communicates with the configuration repository.
Checking and fixing the configuration store
The File Database Recovery utility can be used to perform an offline check of the configuration store. It is not recommended to fix the storage using this utility.
However, if you lose a copy of the latest configuration, you can try to repair the vault database file to obtain the latest configuration from which to create a new vault.
For group development of configurations in the 1C:Enterprise 8 system, a special mechanism is used - configuration store. The configuration storage is a file database into which the configuration is placed using the configurator, and which stores information about the objects currently being edited, as well as the history of changes to these objects. Developer access to the configuration repository is carried out either within the local network or via remote access using a web server. Initially, the configuration is considered as a set of objects that are closed for change. To make changes to an object, it must be captured, and an object can only be captured by one user at a time. After working with captured objects, the result of their modification is placed in the repository, after which these objects become available to all participants in the group development. This way, access to the same configuration objects is controlled, and synchronization of the development team’s work on configuration modification is ensured.
Major industry developments and large modified configurations could not be created without the 1C repository. This is a kind of database in which each developer creates, edits, and debug their metadata. In order to avoid collisions when simultaneously editing objects in the storage, it is possible to capture objects, and after finishing work on it, the developer places it back and removes the capture mark. If something is not satisfactory, any programmer can roll back and restore their previous versions. Theoretically, everything is colorful and beautiful, so let's look at the basic settings and principles of working with 1C storage.
Creating a 1C storage
Since a repository is nothing more than an information base, creating it is very simple. Go to Configuration - Configuration storage Create storage. In the window that appears, indicate the path where the information security will be located, as well as the administrator’s login and password (this user is not associated with database users). Click OK, as a result of which the current configuration will be uploaded to the specified location.
P.S Immediately after creating the repository, create another user with administrative rights, even if only you will work. Why is this being done? I'll explain. It’s not uncommon for a user to “freeze”, and since you have another one, you can go in and remove your own frozen session. The user is created in the Storage Administration section.
Connecting to storage
We already have the actual storage. Now you need to connect users to it. On each developer's personal computer, you need to create an empty database or load into it either a *.dt file or just a *.cf configuration from the main database. After this, you need to go to Connect to storage and enter the username and password that the administrator will provide for each user. As a result of the connection, your local configuration will be completely replaced by the configuration from the repository.
P.S All data from the local information base will remain in place. That is, the configurations are merged without affecting the current database data.
Updating and Capturing Storage
If you have already edited the local database and would like to transfer the changes, then you need to upload the “conf” to a *.cf file. Then you connect to the storage. Your configuration is overwritten. Now you need to capture objects. If you are alone in the database, then we will perform a recursive capture (all subordinate objects are captured) and right-click on Capture to storage on the root configuration element, or capture each object separately if you are working together. Next, go to Compare storage with configuration from file. Voila - all your changes are now in the repository.
The capture method can be set in the window that appears, Fig. 5. Either recursively(1) or allow others to obtain captured objects(2)
As a result of all the work done, the objects must be placed back. The whole procedure happens exactly the same. Select the objects that we captured and right-click, then select Place in storage
However, you can also recursively place objects into storage and release them, or leave them captured.
If several people are involved in the project, then to avoid possible problems and data loss, you need to start every day by getting a fresh configuration from the repository (because other programmers may have made changes). To do this, connect to the storage and right-click on the root configuration element and select Retrieve from storage and perform a recursive capture. Next, if you need to find out who did what, you need to compare it with the database configuration. Afterwards we save everything in storage and work continues.
For group development of configuration in the 1C:Enterprise 8.3 system, use configuration store. Developers can access the configuration repository via a local network (database files are located on a shared network resource), using the protocol tcp or http. The last two options require installation configuration storage server. The configuration storage server, in turn, is a network service that by default “listens” on the port 1542 and ensuring interaction of client applications (configurator) with the configuration storage database. One service can serve multiple configuration stores. About installing the 1C:Enterprise system configuration storage server 8.3 (true also for the version 8.2 ) in the Windows family of operating systems (in the current example - ) and will be discussed in this article.
1. Setting up the configuration storage database directory
The configuration repository server should be installed on the same computer where the repository database files will be located. Therefore, first of all, we will determine the central directory of the server, in which the files of all storage facilities that will be served by this server will be stored. For the purposes of this article, let it be a catalog C:\1C_BASE\repository\. You should also define the Windows account under which the corresponding service will be launched. You can create or use an existing Windows account. In this example we will use a local user USR1CV8 with password UsrPass8. Required for this user to the central directory of the configuration storage server.
2. Installing configuration storage server files
At the time of writing, the configuration store server only exists as a 32-bit application. Therefore, to install server files, you need a 32-bit distribution kit of the 1C:Enterprise 8.3 system for Windows. Run the file 1CEnterprise 8.msi from the 1C distribution kit. On the component selection page, select the component " 1C:Enterprise configuration storage server"(1C:Enterprise configuration repository server), and also remember the installation path of the component.
3. Register and start the configuration storage server service
The installer only copies the configuration store server files to the specified directory. The corresponding service must be registered manually by running a command like:
Crserver.exe -instsrvc | -rmsrvc -usr<пользователь>-pwd<пароль>-start | -stop -port<порт>-d<каталог>
Configuration repository server startup options crserver.exe similar to:
| Parameter | Description |
|---|---|
| -port<порт> | Working port of the storage server. The default port is 1542 . |
| -d<каталог> | Root directory for configuration repositories. The default directory is %APPDATA%\1C\1Cv8\. |
| -instsrvc | Registering the storage server as a service. |
| -rmsrvc | Unregistering the storage server as a service. |
| -usr<имя> -pwd<пароль> |
The name of the user on whose behalf the service will be registered. This user must have the Log on as a service right. In addition, he must have rights to read the directory of executable files of the corresponding version of the 1C:Enterprise system and full rights to the root directory of the configuration repository (directory %APPDATA%\1C\1Cv8\ or the directory specified in the parameter - d) and password for this user. |
| -start | Starting the storage server service. |
| -stop | Stopping the storage server service. |
Register a new service using the program Windows PowerShell, which can be launched by running the command powershell(to do this, press the key combination Win + R, in the window that appears " Execute" (Run) enter the command name in the field " Open"(Open) and press " OK") or by clicking on the corresponding shortcut in the taskbar.
In the Windows PowerShell console that opens, for the convenience of entering further commands, let's go to the directory bin directory with installed 1C:Enterprise files by running the command
Cd "C:\Program Files (x86)\1cv8\8.3.5.1088\bin"
Then, for the purposes of this example, we'll run the command
.\crserver.exe -instsrvc -d C:\1C_BASE\repository -usr .\USR1CV8 -pwd UsrPass8
and start the service by executing
.\crserver.exe -start
Let's go to the service snap-in (which can be launched by running the command services.msc) and make sure that the service with the name 1C:Enterprise 8 Configuration Repository Server registered and launched.
5. Create a new configuration store
As I said earlier, one server can serve multiple configuration stores. The database files for each repository must be located in a separate directory in the central directory of the configuration repository server. Thus, to create a new repository, let's create in the directory C:\1C_BASE\repository\ folder Accounting in which the files of the new configuration repository will be located.
Then to create and connect to this storage you will need to use the line tcp://WIN2012/accounting, Where WIN2012— network name of the computer on which the service is installed, or a string tcp://192.168.0.10/accounting, Where 192.168.0.10 , respectively, the IP address of this computer. You can read more about creating a new storage in the article “”.
It will also be possible to connect to the storage created in this way, bypassing the server, for example, along the path C:\1C_BASE\repository\Accounting on the current computer or along the way \\WIN2012\repository\Accounting if you configure directory sharing C:\1C_BASE\repository on this server.
Did this article help you?
Sooner or later, every developer tries to improve his life. We are not talking about its material component, I am talking about simplifying the work. The more practice you have working on real projects, the more you realize how to do your work more efficiently and correctly.
Today I would like to talk about the use of configuration storage in the process of developing/refining application solutions. I don’t know why many 1C developers avoid using storage capabilities. Especially, I don’t understand those who work on developing one configuration with a whole team. Without a configuration repository there is no way (IMHO) at all. No, you can, of course, engage in perversions like copying one configuration to all developers. Everyone begins to work and realize their part. Upon completion of development, each of the developers must synchronize their configuration with the one that will be delivered to the end client.
With this approach, it is quite problematic to keep track of the relevance of the conference. As soon as two or more developers start working on two related tasks, all hell breaks loose when combining the results of their work. The chances of something being overwritten or combined incorrectly are too great. During my practice, I encountered this situation several times and after another big bump, I decided that I couldn’t live like this anymore.
What is a configuration store
Fortunately, before I got acquainted with the 1C:Enterprise 8 platform, I already had quite good experience in developing in other programming languages (Delphi, PHP). Therefore, words like SVN (Central Version Control System) were not strange to me. For those who have never encountered SVN, I recommend reading the corresponding article on Wikipedia - http://ru.wikipedia.org/wiki/Subversion. Believe me, this is a cool thing and it greatly simplifies the software development process.
So now let's go back to our storage. Configuration repository is a tool of the 1C:Enterprise platform that allows you to organize group development of an application solution. The configuration repository (hereinafter referred to as CS) provides developers with a version control system for the solution being created and flexible options for monitoring changes made by developers.
In what cases can HC be useful to you?
Before listing specific examples, I would like to immediately summarize. Of course, HC will be most useful during team development. However, nothing prevents you from using it purely for yourself. I have been developing on the 1C:Enterprise platform for almost five years and over these years I have repeatedly had to deal with unforeseen situations when the use of HK literally saved me from the nightmare of any developer - rewriting previously written code. Now I try to use configuration storage services for each of my projects. Why? But at least here:
1. History of the repository. This is perhaps one of the most important functions for me. During the development of a solution using CC, a history of configuration changes will be automatically generated. For example, in one work week the configuration was updated several times. All these changes are carefully recorded, and the history is updated with versions. If you wish (or if a hopeless situation arises), you can always look at the list of versions and, if necessary, roll back. For example, on Monday the correct changes were made to the configuration, and on Tuesday a new developer significantly screwed up and posted his upgrades. The result is a configuration with the correct code.
You can, of course, hit the young programmer in the head and then try to restore it manually, or better yet, press a couple of buttons and restore the previous version of the conf or simply roll back the changes made by the would-be developer.
2. Reporting. You can run the report at any time and see who made changes and when (as well as to which configuration objects). This can come in handy when your colleagues throw up their hands and try to prove: “Nasalnik, it’s not us! It just broke!”
3. Remote development. HC is indispensable if an application solution is developed by geographically distant programmers. I don't think this needs to be explained.
4. Minimizing emergency situations. I witnessed several times (in my “youth” and managed to fall into this trap myself) when the developers’ screws broke. Of course, all the latest changes were on those same screws and they irrevocably flew into oblivion. “What about backups?” - you say. No way! Many developers don't like to bother with this. No, only extreme people do not make backups at all, but in my practice I have met very few developers who make backups several times a day. HC elegantly solves this problem. In fact, the developer only needs to press one button and all his developments will be immediately transferred to the repository.
5. Access control. Well, there’s no need to explain much here. HK allows you to configure access restrictions for developers.
There are different types of storage
Initially, the storage facility worked only through a shared resource (in version 8.. This was not very convenient, because if you wanted to organize access to the storage from the outside (for example, via the Internet), problems arose. Starting from version 8.1.11, it became possible to deploy network storages. You can work with them both via the tcp/ip protocol and via http. The latter will be very useful when organizing access to the storage via the Internet.
Figure 1. Storage device diagram
Trying to deploy HC
So, let's assume that you are interested in the idea of using HC and decided to try to deploy it for your project. You already know that storage can work through a shared network resource, or over the network using the tcp/ip protocol. In this post I'll look at deploying storage through a shared resource, and next time we'll look at the network option.
So, the first thing you need to do is prepare the base of your project. You can have it anywhere. If you decide to deploy HC for your live project right now, then don’t be lazy to make a backup copy. Anything can happen and it’s better to be on the safe side.
Create a shared folder on your computer (or directly on the server). Make it common and identify users who will be able to work with it. By users I mean your fellow developers.
The next step is to open your database in the “Configurator” mode and go to the “Configuration” menu -> “Configuration storage” -> “Create storage” (see Figure 2).
Figure 2. Creating a configuration store
Immediately after clicking the “Create storage” button, a window should appear in front of you as in Figure 3. In it you need to select a previously created shared folder or enter the address of a remote storage. Since we agreed to create a storage based on a shared resource, this window will indicate exactly the path as a folder.
Figure 3. Selecting the location of the HC
Once you specify the folder, click on the “Next” button. Before you even have time to blink an eye, the storage creation wizard will display a window for you to create an administrative account (Figure 4). By default, you are prompted to use “Administrator” as your name. It’s clear that nothing prevents you from changing it. In general, enter the desired values and click “OK”.
Figure 4. Creating an administrator account
Here your 1C should think for a few seconds and then offer to connect to the created storage. Answer “Yes.” Congratulations, you have created your first configuration store.
Pay attention to the “Configuration” window. Starting from the very root (this is where the name of the configuration is written), small padlocks appeared on the right side (see Figure 5). This padlock means that the object is currently in the configuration store and you cannot make changes to it. If you need to work with any configuration object, you first need to capture it. I will tell you how to perform this and many other operations on working with storage in the next article, which will appear on the site very soon.
This article describes how to install the 1C:Enterprise configuration storage server service.
Quote from RTFM
In general, if you just need to install a service and get everything up and running, you just need to read the addoc (see below).
To install the service, just run crserver.exe with the -instsrvc parameter and specify the parameters where everything is located, and so on. Everything is trivial and described in sufficient detail in the manual.
To start the configuration storage server, use the following command line switches: for the Windows operating system: crserver.exe -instsrvc -usr<пользователь>-pwd<пароль>-port<порт>-d<каталог>| -rmsrvc | -start | -stop | -srvc -instsrvc - registering the server as a service (service name – 1C:Enterprise 8.1 Configuration Repository Server) -usr - user name on whose behalf the service will be registered. This user must have the Log on as a service right. In addition, he must have rights to read the binary directory of 1C:Enterprise files (by default C:\Program Files\1cv81\bin) and full rights to the root directory of the configuration storage (%APPDATA%\1C\1Cv81\ by default or the directory which is specified in the -d parameter) -pwd - password of the user on whose behalf the service will be registered -port - working port of the storage server. By default, port 1542 is used -d - the root directory for configuration stores. By default, the directory is %APPDATA%\1C\1Cv81\ -start - start the 1C:Enterprise 8.1 Configuration Repository Server service -stop - stop the 1C:Enterprise 8.1 Configuration Repository Server service -rmsrvc - remove the registration of the server as a service -srvc - server operating mode as a service. It is added automatically to the parameters of the registered service. Not used on the launch command line.
How to install two servers on one machine
The trouble starts when you need to install more than one storage server service. For example - for different versions of the platform or for organizing storage on one server for unrelated development teams. There are actually a lot of possible reasons. The crux of the problem is that crserver.exe can install one and only one service - it does not have a command line parameter that affects the service name.
To manage services in Windows, starting with NT4, there is a wonderful console utility SC.EXE. Follow the link to find a comprehensive manual on the commands. The only thing worth adding to this manual is that the parameter name includes the “=” symbol and between this symbol and the parameter value NECESSARILY There must be a space, otherwise sc.exe, instead of useful work, will simply show a short manual for itself. This is noted in the manual, but at the very end, and the most persistent ones usually read to the end and out of despair, when for the 100,500th time what was described in the manual letter-for-letter did not work out.
So let's say we need to deploy two server services. To do this, we need to decide on the following parameters:
Service names are strings that appear in the Name column in the Service Manager. In addition to displaying by name, all manipulations with the service are carried out through sc.exe, so it is recommended not to overthink the name and come up with it as short and succinct as possible without any special characters
In which directories the services will store their data. Theoretically, you can not specify a directory, and then both services will “distribute” the same directory and each storage can be accessed from both services simultaneously.
On which ports both services will listen for connections. The Storage Server service requires one primary port and a range of port 31 to operate. By default these values are 1542 and 1560:1591. These values must be different for different service instances, otherwise only one instance will work - the one that managed to start earlier and open a socket on the based port.
For example, let's assume that:
the names of our two services are 1ccrrep-release and 1ccrrep-trunk
directories (respectively) - C:\1crepository\release and C:\1crepository\trunk
and port+band for each service - 1642+1660:1691 and 1742+1760:1791
The command line to create each of these services would look like this:
C:\>sc create "1CCRREP-RELEASE" binPath= "C:\Progra~2\1cv82\8.2.16.368\bin\crserver.exe" -srvc -port 1642 -range 1660:1691 -d C:\1crepository\ release" start= auto displayname= "1C Storage Server (release)" C:\>sc create "1CCRREP-TRUNK" binPath= "C:\Progra~2\1cv82\8.2.16.368\bin\crserver.exe" -srvc -port 1742 -range 1760:1791 -d C:\1crepository\trunk" start= auto displayname= "1C storage server (trunk)"
cmd.exe, of course, should be run as administrator and these commands assume the deployment of a storage server 8.2.16.368. Progra~2 is “Programm files (x86)”.
It should also be noted that if IIS is used, then access to storage servers must be implemented through separate web applications, and they must have specified different application pools(for example, DefaulAppPool and DefaulAppPool2). If this is not done, then only one storage server will work at a time (to which the first call was made), and the second will generate an error.
What does and does not give 1C storage server
In order to bring a little more completeness to the picture of this article, we should list all the fears and hatreds of all the positive and negative aspects of using server storage.
Pros of server storage
The order of the points corresponds to the order in which they came to the mind of the author of this article; each reader will determine the significance of the advantages for himself:
Isolation of data from the interface. Developers “see” only the service - neither with the repository file, nor with its directory, they cannot do anything other than what they are supposed to do in accordance with the rights in the repository. In the file version of the storage, the rights to the share are the same, and to the storage are different: for example, a user who is simply in the storage, but does not even have rights to capture anything, should still have full access to the share, that is, he can do all sorts of garbage Pile next to 1cd, and damage the file, and copy the entire storage anywhere. In addition, this simplifies the connection to the repository of all kinds of remote developers - to work with the repository, they just need to open several TCP ports and you can not let them into your internal network, and the crserver service will no longer allow them to do anything in 1cv8ddb.1CD , which can be done with the configurator. The maximum is that all sorts of left-handed storages can be created in nearby directories, but this is not a big problem, as they say. In addition, the server service ensures that it is impossible to connect to the repository by any platform release other than the release of the server service itself. That is, no one, maliciously or through sloppiness, will accidentally convert the combat storage to some test new release 8.3, 8.4 or even 9.0 - crserver simply will not allow non-Orthodox clients.
Independence from the actual storage location of the 1cv8ddb.1CD file - you can move the file and change the internal directory structure and at the same time the connection string for storage users will not change - just know change the parameter -d at the crserver service. In principle, the same is possible with a file storage, but in the case where there are many storages from different ISs, it may not always work out. Or, if all storages initially have one directory, then it is no longer possible to separate them into different ones without changing the connection string in the file version.
Using server power And for storage operations. All reading and writing operations in 1cv8ddb.1CD are performed by the crserver service and the processor of the machine on which it runs. In the file version, all operations are performed by the client processor.
A nuance in 8.2
In 8.2.* crserver is a single-processor application. This leads to a number of unpleasant disadvantages, which are discussed below. In 8.2, the disadvantages of server storage compared to file storage entirely arise from the latter “plus”. The crserver service itself does not do anything useful - it is just a relay of requests from clients. This is why the crserver version must exactly match the client version. And this is precisely why you can share the service directory and access the storage both as a file storage and as a server storage. Moreover, you can even deploy two crserver services, point them to the same directory, and from two parallel services everything - captures, placement, reading, and so on - will work the same as with one service or without services at all. So, here they are, the “cons”:
Single-processor crserver. The crserver service can only work with one processor, so it will, of course, use the power of the server, but only one processor. If there are many users, then it will queue them up for the resources of one server processor, regardless of whether how many other processors on the server are sleeping.
Few users or highload? no, have not heard". Although the repository itself is a team development tool, the repository server is not such a tool. This is nothing more than a means of hiding the physical location of the 1cv8ddb.1CD file from users. If there are several early repositories and the number of developers is more than 10, then for normal operation each repository needs its own crserver service. Because the service is limited by the computing resources of one processor and for some other reason that the code of this service is crammed with crutches - the practical experience of the author of the article of transferring several storages with 100+ users in total and 30+ parallel ones to the server version showed a drop in performance on those storages that Before this transfer, they had never slowed down because they were small (1cv8ddb.1CD up to 500MB). Because users of even small storages line up in one common queue to one processor in a meager number of threads (task manager shows a monstrous discrepancy between the number of live connections to crserver.exe and the number of threads created by the process - 7 threads were created for 23 connections during observations in combat conditions carried out by the author of the article)
conclusions
On the 8.2 platform, the crserver service, due to its single-processor nature and “a bit of threading,” is not a means of collective development. It is a means of providing access to storage over a set of abstract tcp ports, so as not to give clients access to either ftp, cifs or smb (here’s to you, remote Vasya, 32 tcp ports, have fun with all your money). For large teams, it doesn't make sense to use server storage for anything other than providing limited access to remote developers. Although the latest intelligence clearly illustrates that it is better not to even think about it.
However, in 8.3 crserver suddenly became multiprocessor. The author of the article does not have reliable information about which release exactly multiprocessor happiness began with - a search in changelogs on this topic did not produce results, but it is reliably known and confirmed experimentally that already on 8.3.4.408 crserver loads all the processors that are in the system.
Loading...
