Hi Uli,

These 2 lines in the usys.asn seem to be enough to deploy the whole application only on  a server. The application asn maps all objects to the $POLYSERVER path. On the client only Uniface is installed and we had the usys.asn changed. That's all.

Why delete messages?

kind regards,

Peter

Hi Peter,

It is helpful to "clean up" (sometimes to delete the whole topic if the discussion went out of bounds).
Think about users like me who come back after some months/years (as I do on T.U.R.F or the listserver)
and are only interested in the "mainstream" information.

Same goes for notes etc. which are out of date, so why not put them in the delete-bin?

Success, Uli

Well, in both V8 & V9 we have used the following in the client

$DNP TCP:servername|userver|userver|support
$files TCP:servername|userver|userver|FILES
$DATA/net TCP:servername|userver|userver|support
$DATA $DATA/net
$SSV TCP:servername|userver|userver|support
$ASV TCP:servername|userver|userver|support_SVC

in the client and

SUPPORT = userver.exe -dir="appdir" /deb -asn=pci_support_srv.asn -maxidle=5n
SUPPORT_SVC = userver.exe -dir="appdir" /deb -asn=pci_support_srv.asn -maxidle=5n
SUPPORT_AUTO = userver.exe -dir="appdir" /deb -asn=pci_support_srv.asn -maxidle=1n
SUPPORT_AUTO_SVC = userver.exe -dir="appdir" /deb -asn=pci_support_srv.asn -maxidle=1n

in the urouter.asn.

We do, however, have to make sure we activate ALL our services as activate/stateless to prevent one user being hung up on another.

Before that we used to use the -ex switch somewhere. Which gave the behaviour you show. (One or more servers per user).

We don't ship the .asn and .ini via the userver though. I don't know if that would hold the server process open as the files are 'in use'.

Have you checked out the servers in the urouter monitor and turned on logging in the server .asn files to see what they are actually doing? If maxidle doesn't work, it indicates that they are permanently 'busy'.

Hi Peter,

heapsize is the "upper" part of the computer memory (allocated memory).
The "bottom" part is the stack; whenever you call an operation,
the parameters etc. are put on the stack.
On return of the operation, they are removed from the stack (First In, Last out) again.

For your problem, you may find a hint at:

mhashem.wordpress.com/2008/08/25/set-tomcat-memory-heap-size/

wiki.answers.com/Q/What_is_heap_size_in_Java

Success, Uli

Peter,

Maybe this article (published on Frontline) is useful: Maximize the number of UServers that can run on Windows by using the Desktop Heap efficiently.

Best regards,
Daniel

**********

Maximize the number of UServers that can run on Windows by using the Desktop Heap efficiently

Release : 8.0

Last Updated :15-May-08

Maximize the number of UServers that can run on Windows by using the Desktop Heap efficiently.

The UServer process is using Desktop Heap. There is a system-wide buffer of 48 MB by User32.dll. Taking into account that the current interactive process also takes 3 MB from this buffer, 45 MB remains for *all* processes that use User32.dll. Each UServer user will take 512 KB from the system wide buffer.

There are 2 improvements to maximize the number of UServers that can run.

The first improvement:

When the urouter service is running under the 'LocalSystem' account, enable the 'Interact with desktop' checkbox. When you do this, all UServers will inherit the Desktop Heap of the logged on user, thus avoiding the problem associated with the taking of 512 KB from the system-wide buffer of 48 MB by User32.dll. Even with this setting every UServer will use a couple of bytes from the Desktop Heap. The difference is that when started as a "normal" service the UServers will claim the amount of bytes defined in the third value of "SharedSection" and not only the amount necessary.

For this improvement we made a change in patch C202 via bug 25549:

UServer user requires admin privileges when 'Interact with desktop' is used. With the solution of Bug 25549 it is not necessary to start the UServers under the local admin account. The fix allows the UServer processes to interact with the desktop without admin rights if the UServer user is a member of the 'Uniface Server Users' group.

The reason for this fix:

The only users that have full access to the desktop are LocalSystem, and the currently logged on user. Certain user API calls may not work if the UServer-user is not in the local Administrator group, and is not the currently logged-on user, depending on the security needs. In this case, the CreateProcessAsUser call fails without any indication, i.e. no UServer is started. There is the Microsoft Knowledge Base article "Q184802 - PRB: User32.dll or Kernel32.dll Fails to Initialize", which explains a few things:
http://support.microsoft.com/default.aspx?scid=kb;en-us;184802 and the following MS KNB article covers security issues when a service interacts with the desktop: "Q327618 - INFO: Security, Services and the Interactive Desktop": http://support.microsoft.com/default.aspx?scid=kb;en-us;327618

The second improvement:

A maximum of (45 MB / 512 KB =) 90 UServer processes can run on any Windows NT, 2000 or XP machine. Since most people have other services running that also take their 512 KB from the buffer, it will be less than 90. Fortunately, this number, 512 KB, can be changed in the registry. By lowering it the number of UServers that can run can be increased. The minimum value however is 128 KB, so no more than (45 MB / 128 KB =) 360 such processes can run on Windows. The registry setting is [HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\SubSystems\\Windows]. Its value is a rather large string. Inside this string, the text "SharedSection=1024,3072,512,512" occurs on a standard Windows 2000 machine. The third number, 512, specifies the number of bytes taken from the 48 MB buffer per non-interactive process. Lowering this to 128 will allow 360 such processes. The second number, 3072, is the 3 MB mentioned above.

Note that lowering the 512 to 128 will work for Uniface UServer, but may cause problems for other applications, which might actually need all 512 KB."

Some testing has been done on a test machine using Windows 2000 Advanced Server with enabled Terminal Services. Using different Desktop Heap settings, the following amount of UServer processes could be started:

"SharedSection=1024,3072,512,512" = 28 UServers [DEFAULT for Windows 2000 Advanced Server using Terminal Services]
"SharedSection=1024,3072,256,512" = 59 UServers
"SharedSection=1024,3072,128,512" = 123 UServers
"SharedSection=1024,2048,128,512" = 131 UServers

Note: The number of values following the "SharedSection=" control might differ from system to system. More information concerning this topic can be found in the Microsoft Knowledge Base Article Q184802: http://support.microsoft.com/default.aspx?scid=kb;en-us;184802

Hi guys,

To be honest, since a few days I know about this heap size. Unfortunately the Hongerian (!) system administrators don't. To change the heap size, we have to move heaven en earth. For that reasons we are looking for a work around.

I just cannot believe that we can only use a very limited number of UServer processes. How do other Uniface users do this?

And, perhaps the most silly question ever on this forum, can we share polyserver processes on the server? Now, for every enduser a polyserver process is started. If we can limit this number of polyservers, we can do with less userver processes.

KInd regards,

Peter

Hi Uli,

I suppose where off-topic now and we should be banned for a few hours by a moderator :)

The polyserver doesn't perform any action, besides delivering a component to an Uniface process on a client. So the real processing takes place on a client and not in the userver process.  Now even an user who is staring to his screen allday long is claiming 1 userver. Even setting the maxidle doesn't work...

regards,

Peter

Hi Uli,

It wasn't that late, last night, was it? It's all about using the right vocabulary. What you describe is not what we are doing, that's what I always called the ApplicationServer (ASV). Your story is simular to www.compuware.com/products/uniface/resources/6900_ENG_HTML.asp.

We use URouter/UServer to serve us the components. See the example of the usys.asn in my first post. It's more a fileserver, the way we use it.

Kind regards,

Peter

Hi Peter,

agreed, you use it only to retrieve INI and ASN files

So what about to put the activation of uniface in a command script and use copy or so to bring the files to the client?

Success, Uli

P.S. will delete some of my replies here, which do not match the current question