Best Of

Hi Pascal,

Ice 3.5.1 is quite old and we don't really support it anymore other than for commercial projects that still depend on it. I'm not surprised it doesn't build with recent OpenSSL APIs. When Ice 3.5.1 was released, it supported OpenSSL 0.9.8. The release notes which include build instructions and supported platforms are accessible from the Ice 3.5 download page: https://zeroc.com/downloads/ice/3.5

Do you have a specific need for Ice 3.5? I really recommend to use the latest Ice 3.7 version instead.

For Ice 3.7, the release notes are also accessible from the download page: https://zeroc.com/downloads/ice/3.7 but we moved the "Build from Sources" instructions to the GitHub source tree instead in the README.md file of each language mapping directory.

For C++, see the build instructions are here https://github.com/zeroc-ice/ice/blob/3.7/cpp/README.md

The C++ source tree provides two different C++ mappings for Ice, the C++98 mapping and the C++11 mapping. It also supports different build configurations (static, shared for Unix platforms, xcodesdk for macOS). On supported platforms, you can view the different build configurations by executing

$ make print V=supported-configs

You can then build multiple configurations/platforms using make. For example, on Linux to build both the C++98 and C++11 mapping with shared libraries:

$ make CONFIGS="shared  cpp11-shared"

The "shared" build configuration is to build the default C++98 mapping and the "cpp11-shared" configuration is to build the C++11 mapping. Our CI build Ice from sources everyday on our supported platforms, so I'm confident it still works

Note that you don't have to specify -DICE_CPP11_MAPPING when building Ice sources. You only need to specify this when building your programs against Ice (we use the same set of header files for both the C++98 and C++11 mapping and this macro allows to pick the C++11 version of the headers when building your program).

I believe some of the 3.7 build errors you got are caused by specifying the ICE_CPP11_MAPPING macro.

If you are not using a supported platform, can you try to run make in the ice/cpp directory (to build the C++98 mapping)? And then try to run make CONFIGS=cpp11-shared (to build the C++11 mapping)? There's no need to clean between the two builds. Can you provide the errors you get from running these two build steps?

Can you provide information on the Linux distribution and the compiler version that you are using when build Ice sources? What is the output of make print V="supported-platforms supported-configs"?

Cheers,
Benoit.

There is no support for modifying the process PATH in IceBox, a third option will be to distribute icebox.exe and in its dependencies with your application and run everything from the application folder.

After starting the configured services, it activates the service manager adapter if "IceBox.ServiceManager.Endpoints" was set, and then prints ready message if "IceBox.PrintServicesReady" was set, once that is done it return control to Ice::Service class that will notify Windows that the service was started.

Did you check icebox.exe is run with --service?

sc qc icebox
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: icebox
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Program Files\ZeroC\Ice-3.7.4\bin\icebox.exe --Ice.Config=D:\3.7.4\ice-demos\cpp98\IceBox\hello\config.icebox --service icebox
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : IceBox Server
        DEPENDENCIES       :
        SERVICE_START_NAME : NT Authority\LocalService

Check the BINARY_PATH_NAME and make sure --service argument is there

Also try setting IceBox.PrintServicesReady and see if the ready message is in the log, this will indicate that IceBox start correctly.

The configuration file format doesn't allow for setting a property to a multi-line string, you can create a property set by calling createProperties and the use setProperty as needed.

See https://doc.zeroc.com/ice/3.6/properties-and-configuration/setting-properties

Hi,

You didn't miss something, there's currently no way to set this at the topic or subscriber level, it's a global IceStorm configuration. The queue size max configuration was designed as a protection for IceStorm to avoid consuming too much memory if a client doesn't consume its events or not fast enough.

Can't you set this property to a value large enough to satisfy all the subscribers? Or do you want to rely on this property to unsubscribe or drop events events for slow subscribers automatically?

As a workaround, you could instantiate different IceStorm service instances in the same IceBox server with different configurations but I understand that it's not ideal.

Note that we also released recently a new service called DataStorm, you might want to take a look at it as well.

Cheers,
Benoit.

Hi Mike,

Ice cannot directly send your named tuples, you have to use types defined in Slice, here you can probably use a couple of structs and sequences like in:

struct BenchmarkCount
{
    long Data; // Send date as a long
    int Count;
}

sequence<BenchmarkCount> BenchmarkCountSeq; 

struct BenchmarkInfo
{
    string Key;
    int Benchmark;
    BenchmarkCountSeq Counters;
}

sequence<BenchmarkInfo> BenchmarkInfoSeq;

There is no __copyFrom in 3.7 seems you still have some object files from your 3.5 build

Hi,

The slice2cs compiler included in the NuGet package is a Windows binary, for Linux/macOS you need to install the ice compilers

See https://zeroc.com/downloads/ice/3.7/csharp#redhat and https://doc.zeroc.com/ice/3.7/release-notes/building-ice-applications-for-net

It should work without setting IceToolsPath after installing the Slice compiler

Hi,

You should check the 3.6 release notes for information on the timeout changes, see https://doc.zeroc.com/ice/3.6/ice-release-notes/upgrading-your-application-from-ice-3-5#id-.UpgradingyourApplicationfromIce3.5v3.6-Timeoutchanges

Setting Ice.Default.InvocationTimeout=-2 should provide the previous behavior. It isn't clear from your description if this will solve your issue however. Let us know how it goes after this change.

Once it works, I recommend considering changing to the timeout semantics.

Cheers,
Benoit.

Hi Jean Christophe,

Did you try replacing Ice::Service with Ice::Application in your test app? That's really the only major difference I can think of between IceBox and your test app.

In any case, it sounds like your making good progress to get to the bottom of this. The easiest way to figure out the problem would be to get a stack dump of the hang, for this you need the PDBs of the release 3rd party DLL.

Also note that IceBox isn't a requirement for running Ice services on IceGrid... you could also very well just implement your service as a regular executable linked with the 3rd party DLL if this issue can't easily be worked around.

Cheers,
Benoit.