Home Help Center

Advanced configuration of IcePatch2 using IceGrid

flheflhe Member Florian HebelOrganization: Hebel Consulting GmbHProject: Plain Vanilla & Structured Derivatives Sales Tool
Hi guys,

thank you for the great work you're doing. :-))

Currently I'm trying to get out the most of your cool IcePatch2 (3.4) service
and I have two questions for you:

1.) I wonder whether it is possible to specify something like
<distrib icepatch="IcePatch2${environmentname}/server"
locator="UspPluginContainer/Locator:default -h someServer -p 4061">
in order to use the locator of a remote server (i.e. without knowing the actual
port, on which the specific IcePatch2 server is running).

The aim is to deploy the binaries and the IcePatch2 server only on one machine
and to distribute the servers to several independent installations on other servers.

2.) Is it possible to specify some xml-attribute in the <distrib> section, which automatically
performs a patch of the server before starting it? This would be extremly nice in particular
if it was a new installation and there are no binaries at all in the target location.

Snippet of my current configuration:

<server-template id="USPCachingServer">
<parameter name="environmentname"
default="Developer" />
<server id="USPCachingServer${environmentname}"
<distrib icepatch="IcePatch2${environmentname}/server">
<adapter name="USPCaching"
<object identity="USPCaching${environmentname}"
property="Identity" />
<server-template id="IcePatch2">
<parameter name="environmentname"
default="Developer" />
<parameter name="endpoints"
default="default" />
<parameter name="directory" />
<server id="IcePatch2${environmentname}"
<adapter name="IcePatch2"
<object identity="IcePatch2${environmentname}/server"
type="::IcePatch2::FileServer" />
<property name="IcePatch2.InstanceName"
value="IcePatch2${environmentname}" />
<property name="IcePatch2.Directory"
value="${directory}" />
<node name="localhost">
<server-instance template="IcePatch2"
directory="D:\dev\usp\IceBox" />
<server-instance template="USPCachingServer" />

Thanks in advance for your advice and your suggestions.

Best regards



  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Florian,

    Welcome to our forums!

    The <distrib> element has no secret undocumented extension :).

    In particular, for (1), you provide a stringified proxy to the icepatch attribute, and this proxy can be either an indirect proxy (using the deployment's IceGrid registry for location) or a direct proxy. It can't be an indirect proxy associated with a different locator!

    It sounds like a direct proxy would work for you: you'd configure your IcePatch2 server to use a "direct" object adapter, and you could deploy it in just one IceGrid deployment (or on its own, with IceGrid). At the same time, you may want to double-check your overall concept. If you have several IceGrid deployments that are connected (they share the same distributions), perhaps a single IceGrid deployment would make more sense?

    For (2), application/server patching is a manual process initiated through the admin tools. There is no option to automatically "patch" a server upon installation on a node.

    In practice you could use the following procedure to install a new server:
    - create a new server descriptor, with an associated distribution and also "manual" activation
    - deploy this server on a node
    - patch the server
    - start the server with the admin tool, or change its activation to "on-demand"

    If you want to automate all this, you could write a little application in Python or Java that does all this. All IceGrid admin feature are available programmatically.

    Hope this helps!
Sign In or Register to comment.