Best Of

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.

I was looking at this definitions in https://github.com/ome/omero-blitz/blob/718d598a49c0a5db1e0a7752200d07f1ef9b472a/src/main/slice/omero/Tables.ice#L130

My understanding is that the error is not related to the rowNumbers param but with the marshaling for the Data::columns, can you dump the Data::colums to check if it has the expected values. I assuming here you are marshaling StringColumn and it contains and unexpected (not string) value.