ICE 3.4.1 and Qt 4.7
quadbyte
Member Thierry WilmotOrganization: Société GénéraleProject: trading tools ✭
in Help Center
Hello All,
Is there any 'official' paper from ICE team about running ICE 3.4.1 and Qt 4.7 since the old Matthew one on issue15 "Integrating Ice with a GUI" and the last "New Ice 3.4.0 AMI and Qt 4.5 library" from mwilson ?
Regards,
Thierry
Is there any 'official' paper from ICE team about running ICE 3.4.1 and Qt 4.7 since the old Matthew one on issue15 "Integrating Ice with a GUI" and the last "New Ice 3.4.0 AMI and Qt 4.5 library" from mwilson ?
Regards,
Thierry
0
Comments
Sorry, we do not have any new material covering Qt 4.7. Matthew's article is out of date as it doesn't cover the new functionality brought with Ice 3.3 and 3.4 which are namely: non-blocking AMI calls and the [noparse]Ice::Dispatcher[/noparse] interface.
Both allow to significantly reduce the complexity of making Ice calls from the GUI event loop thread. You can safely make Ice invocations from the GUI thread with AMI and you can directly receive AMI callbacks in the GUI thread.
Alex's QtDispatcher implementation on this thread should be a good starting point on how to use the Ice dispatcher interface with Qt.
You might also want to check out the MFC demo from the C++ demo/Ice/MFC directory which demonstrates the integration of MFC with Ice (in a very similar way, by implementing an Ice dispatcher that dispatches AMI callbacks and requests in the MFC event loop).
Let us know if you need more information on this!
Cheers,
Benoit.
I try to start with DispatchEvent sample given by Alex Makarenko, not so far from official MFC exemple, but the customEvent() is never called and my app is freezed...
Thierry
module X { interface Y { ["ami"] void doSomething(); }; };In your GUI you would call "begin_doSomething()". This guarantees your GUI will not hang. There is good documentation at ZeroC - White Papers and Articles for C++, Java, C#, and Python on using AMI.
Things was not clear for me, and I thought that only mixed sync and async calls was prohibited.
Anyway my freeze appears on a Qt GUI server app when calling
or after init step each time I use proxy object to send my Storm feed.
May be cause storm calls are not AMD mode, but does it make sense to make AMD call for Storm publish function ?
Thierry
Under the hood, the checkedCast call does perform a synchronous call to the IceStorm server to verify the that the Ice object correctly implements the TopicManager interface. As Mark mentioned, you can't do synchronous calls from the Qt thread if you use the Ice dispatcher: the synchronous call will wait for a response but this response can't be received because Qt thread is stuck waiting.
So here, you should use an uncheckedCast instead to avoid making the synchronous call to IceStorm:
Cheers,
Benoit.
I try to start publisher binary on another machine and keep storm and consumer on the same machine.
I experiences some random freeze on the publisher componant : All the initialize stuff seems to be ok (no exception), but during the first call to the proxy method (in the Qt thread), the call could randomly freeze (until timeout) and then run fine.
I put in config.pub the Ice.Trace.Network=3, and here is what I saw:
My diagnostic is that all seems to be ok, and connections are established between both machines (198.168.1.2 and 192.168.1.5).
Then I calls my proxy method, and the trace reveal this:
Why the network try to establish a connection with 172.16.6.1 never traced about before ??????
This is not always 172.16.6.1 on each debug session I launch, but that could explain why the calls are freezed until timeout.
Does anybody have idea ?
Here is my config files:
config.pub
config.icebox
config.service
Thierry
I think I found the problem. As describe in config.service there is no 'connection' between the location of the service for IceStorm.TopicManager and the location of IceStorn.Publish. For me it make sense that both was located on the same machine, and if the TopicManager connection was ok, then the Publish connection was on the same machine.
If I specify host on the IceStorm.Publish this way:
problems seems to disappear .... but it is quite strange that some connections worked fine, the connection list seems not to be ordered the same way each started session.
Thanks Mark to put me on the way
Thierry
When you don't specify the -h option for the endpoints property, the IceStorm service listens on all available network interfaces and the proxies it creates also include the endpoints of each each interface.
When your publisher invokes on a proxy with all those endpoints and if the connection isn't established yet, it randomly picks an endpoint and tries to establish a connection to this endpoint. The fact that the endpoint is randomly picked explains why it sometime hanged and sometime didn't. If you had configured timeouts, you would have seen that the connection establishment would eventually timeout and the Ice runtime would then have tried establishing the connection using another endpoint.
For more details on how connection establishment works with Ice I recommend reading Chapter 36 - Connection Management.
Cheers,
Benoit.