Jump to content
OpenSplice DDS Forum

e_hndrks

Members
  • Content Count

    77
  • Joined

  • Last visited

About e_hndrks

  • Rank
    OpenSplice_DDS Expert
  • Birthday 11/30/1973

Profile Information

  • Gender
    Male
  • Location
    Hengelo, Netherlands
  • Company
    ADLink
  1. This issue will be solved in the upcoming V6.10.2p3 release.
  2. Hi Davide, I think you are using the 'classic' Java API, where Hans was referring to the newer Java5 API. With respect to factories: the Participant acts as a factory for both its Publishers and its Subscribers. You can obtain the default qos settings from a factory using the get_default_xxx_qos(), so for example for the Publisher you would do this: PublisherQosHolder pubQos = new PublisherQosHolder(); int status = participant.get_default_publisher_qos (pubQos); ErrorHandler.checkStatus(status, "DDS.DomainParticipant.get_default_publisher_qos"); pubQos.value.partition.name = new String[1]; pubQos.value.partition.name[0] = "<Some partition name>"; Publisher pub = participant.create_publisher(pubQos.value, null, STATUS_MASK_NONE.value); Hope that clears things up. Regards, Erik Hendriks.
  3. Hi Davide, The problem here is that you use the PUBLISHER_QOS_DEFAULT as a value, where it is actually interpreted as a reference. It is supposed to be this "magical" reference that when encountered is substituted by the default Qos setting in your factory. In your first statement (SubscriberQos subQos = SUBSCRIBER_QOS_DEFAULT.value;) you don't make a deep copy of the value of the SubscriberQos, but instead you just copy the "magical" reference instead. When applied, the create_publisher/create_subscriber calls recognize the "magical" reference and substitute it by the factory default for the Publisher/Subscriber in question, without looking at its actual values. What you should do is to obtain the default value from the factory using the appropriate call (get_default_xxx_qos) and then modify the partition of the resulting value. Regards, Erik Hendriks.
  4. Hi Jami, The list of Conditions you pass to WaitForConditions is meant to be an output-parameter, not an input parameter. In other words, you are expected to attach the conditions you want to be triggered on to the WaitSet, and WaitForConditions returns to you the subset of Conditions that actually triggers. You seem to use the parameter as an input parameter, but if you haven't attached your condition using attachCondition prior, there is nothing for the WaitSet to trigger on. Regards, Erik Hendriks.
  5. Hi Emmanuel, Which version of OpenSplice are you using? This issue has been solved from OpenSplice V6.6.0p3 onwards. Regards, Erik Hendriks.
  6. Hi Harald, Your problem probably occurs when you are using the Single Process Deployment mode. I guess your test application runs out of its main when you are done writing your data? What happens is that your application creates a Writer, pushes a sample onto the network stack, and then runs out of main, effectively terminating your networking service before it got the chance to push the sample onto the network. In the Shared Memory Deployment mode the lifecycle of your networking service is not tied to the lifecycle of your application, and you will see that in that case you don't run into this problem. A little sleep between the write call of your application and your application running out of its main will probably do the trick in that case. Another possibility is that your application does not run out of its main after the write call, but the networking service rejects your message due to its queue being filled up to the max. In that case an invocation to wait_for_acknowledgements before having your writer run out of scope will block your application thread until the Writer has been able to successfully insert the message into the queue of the networking service, after which the writer can be deleted without loosing any of the data that is still in the writer's history cache. Regards, Erik Hendriks.
  7. Hi, You cannot register instances on the Reader side, but you can specify boundaries to how much data you are willing to store on the reader size in worst-case. The ResourceLimitsQosPolicy of the DataReader will allow you to specify how much samples you are willing to store in your reader cache. You can minimize the use of mallocs by using read/take calls with pre-allocated buffers (as opposed to using the loaning mechanism which does allocate the buffer on each subsequent invocation of read/take), and re-using this pre-allocated buffer in each subsequent invocation of read/take. Keep in mind though that there are a number of hidden calls to malloc/free that you can not control: the contents of each string will be allocated separately, and the buffer of each sequence as well. For sequences you can pre-allocate the buffers to your worst-case size. and re-use them in subsequent calls, but for strings you cannot. If you really want to avoid that, you should model strings as inline character arrays, but the question is if the performance benefit (often not that spectacular) outweighs the cumbersomeness of such an approach. Regards, Erik Hendriks.
  8. Hi, If you want to use the same data model in both DDS and CORBA, you will have to use the CORBA Cohabitation mode. However, the CORBA files delivered with OpenSplice only cover a limited amount of CORBA versions, and most of them are pretty old by now and some seem to have symbols that clash with modern Linux kernels. We recently (from version OpenSplice V6.10.2 onward) added support for the latest ACE (V6.5.0) - TAO (V2.5.0) in our ORB abstration layer, which should make CORBA-Cohabitation also work on modern Linux kernels again. Regards, Erik Hendriks.
  9. Hi Jan-Marc, We use the cygwin environment only for tools like make, flex, bison and the bash scripting: the OpenSplice source code is still compiled with the Microsoft compiler from within the cygwin environment. Basically that means the resulting libraries and executables are identical to versions that would have been built as Visual Studio projects. The advantage of this is that you have seamless integration with most of the software that is deployed on the Windows platform. In the very past we used to build using the cygwin provided compiler and linker toolchain, but the resulting libraries (in particular static libraries) were not always usable for Visual Studio developers. Hence the move to the Microsoft comiler. If you want to build the product again using the cygwin toolchain, you might be in for a very big job. Not only would this severely impact all the makefiles, it would also impact the Windows abstraction layer that now uses calls directly into the Microsoft kernel instead of into the cygwin POSIX layer. Not impossible, but a lot of work. Because the benefits of supporting the native cygwin toolchain do not outweight the effort, we have no plans to support such a configuration at the moment. But of course you are free to experiment yourself. Regards, Erik Hendriks.
  10. Hi Jan-Marc, If you only use TRANSIENT_LOCAL and VOLATILE (in other words, you don't use TRANSIENT or PERSISTENT), then you technically don't need to run a durability service. However, due to a bug in the product the function wait_for_historical_data only works when you have a durability service running: if that is not the case it will never unblock unless the specified timeout expires. Since some of the tools (e.g. Tester) invoke a wait_for_historical_data with unlimited timeout on all non-VOLATILE readers, the tool 'hangs' when no durability service is configured. I think that is what Hans was trying to explain. For your information, the bug in question has been identified and is scheduled to be fixed in the upcoming commercial release. Regards, Erik Hendriks.
  11. In OpenSplice the typename you pass to the register_type operation is only used inside the participant itself to locate the the meta-data given the type_name parameter of your create_topic operation. However, in the builtin topics the IDL name is always advertised, regardless of the type_name you specified in your register_type call. This is to avoid two applications compiling the same IDL but using different type_names from not being able to communicate with each other. The IDL typename used in the builtin topic is always fully scoped, using the IDL scoping operator "::". So interopeability with other vendors is going to be hard if you do not pick the IDL type name when registering your datatype.
  12. Hi Luca, When using header files from only include/dcps/C++/SACPP (in other words, you are using the Classic StandAlone C++ API) you should link to only libdcpssacpp and libddskernel.so. When you are using header files from the new C++ API (include/dcps/C++/isocpp2, keeping in mind that include/dcps/C++/isocpp is deprecated) you link to only libdcpsisocpp2.so and libddskernel.so. Regards. Erik Hendriks.
  13. The problem seems not to be in the include guard, because A.idl, B.idl and C.idl are all compiled independently. It is at link-time that you run into this issue since each compiled object file now has the same symbol. I will look into a way around this, but in the mean time you might want to circumvent the issue altogether by getting rid of the anonymous sequence, by putting a typedef in the file that hosts your T_IdentifierType type, and then referring to that typedef from A.idl, B.idl and C.idl. So as an example, let F.idl look like this: struct T_IdentifierType { T_Int32 A_resourceIdentifier; T_Int32 A_instanceIdentifier; }; typedef sequence<T_IdentifierType> T_IdentifierTypeSeq; And then use a reference to T_IdentifierTypeSeq in your other IDL files instead of using anonymous sequences there.
  14. Hi Payne, To complement Hans' suggestion, you could modify your code in the following ways: On the Publishing side, follow your write instruction immediately by a corresponding unregister instruction. This instructs the Writer to release all resources allocated to accomodate for future updates to that instance. Not doing this is what causes your memory leak. status = HelloWorldWriter->write(msgInstance, DDS::HANDLE_NIL); status = HelloWorldWriter->unregister_instance(msgInstance, DDS::HANDLE_NIL); Instruct the Writer to automatically unregister after each Write instruction by setting the (OpenSplice specific) autounregister_instance_delay to 0 on the DataWriterLifecycleQosPolicy in your WriterQos. DDS::DataWriterQos wQos; result = publisher->get_default_datawriter_qos(wQos); result = publisher->copy_from_topic_qos(wQos, tQos); wQos.writer_data_lifecycle.autodispose_unregistered_instances = false; wQos.writer_data_lifecycle.autounregister_instance_delay = DDS::DURATION_ZERO; writer = publisher->create_datawriter(topic, wQos, NULL, DDS::STATUS_MASK_NONE); Regards, Erik Hendriks.
  15. Indeed the ISOCPP2 implementation comes with a new IDL compiler backend that is a complete re-implementation of the one used for the now deprecated ISOCPP. So there is a good chance that it will do a better job. If not, then please let us know as well.
×
×
  • Create New...