Jump to content
OpenSplice DDS Forum
sergione83

Touchstone benchmark weird behavior

Recommended Posts

Dear OpenSplice team,

 

lately I am trying to use your benchmark tool, also known as the

Touchstone project.

 

First I wonder why I can't find any link to the project on the brand

new OpenSplice website. Is the project still on?

 

Furthermore I got some weird responses from the tool. If I run the

"tutorial" scenario and then I kill (or simply shutdown) the

OpenSplice daemon I see that the Transceiver and the Transmitter still

exchange data and no error is returned by the "watcher" or the running

processes. Which entity is delivering the data in place of the

OpenSplice daemon?

 

Thanks for any feedback.

 

Best regards,

 

Sergio

Share this post


Link to post
Share on other sites

Hi Sergio,

 

Sorry for the delayed reply.

 

First I wonder why I can't find any link to the project on the brand

new OpenSplice website. Is the project still on?

 

Very much so - it's linked with the other related projects on this page http://www.prismtech.com/opensplice/opensplice-dds-community/related-projects . Sorry for the confusion.

 

Furthermore I got some weird responses from the tool. If I run the

"tutorial" scenario and then I kill (or simply shutdown) the

OpenSplice daemon I see that the Transceiver and the Transmitter still

exchange data and no error is returned by the "watcher" or the running

processes. Which entity is delivering the data in place of the

OpenSplice daemon?

 

Delivery of data does not require the mediation of the splice daemon. The daemon handles a number of vital ongoing management roles but data is propagated via a shared memory segment mapped into the application and service processes. This ensures that the daemon does not become a performance bottle neck in the circumstances where performance is the most critical. This is why you can sometimes see applications 'run on' after the daemon process has been inappropriately terminated for as long as the application does not access any function that requires the daemons presence.

 

The first point is that you should not do this - you should design your system such that the daemon process will both precede and outlive your connected application processes. In the event that the daemon process is terminated however then the next release will include a feature such that application processes will detect this and return an error, so your app can take appropriate action, from any & all DCPS operations that take place after daemon termination + a user configurable Lease/ExpiryTime (refer 3.2.3 Element Lease in the deployment guide).

 

In the near future we are also planning to make an alternate architecture possible where the OpenSplice daemon, and other services, functions can be collocated into the application process instead of running separately. This will optionally make all of this a no brainer in systems where managing the mutliple process lifecycles is a concern.

 

Cheers,

Simon.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×