I use DDS Opensplice community version 6.7.
At the moment when I create a topic, I use QoS xml configuration file. The QoS config file sets settings such as liveliness and resource_limits for a topic.
I know that if you don't use QoS config file, which default QoS will be used, you can use "dds::core::policy::WriterDataLifecycle::ManuallyDisposeUnregisteredInstances()" to manually register/unregister/dispose topic instance.
I want to know while I using the QoS config file, how can I do the same to manually register/unregister/dispose topic instance?
Is there any entry in QoS config file that corresponds to ManuallyDisposeUnregisteredInstances?
If you use
dds::core::policy::WriterDataLifecycle::ManuallyDisposeUnregisteredInstances
Documentation states:
Returns
a WriterDataLifecycle QoS instance with autodispose_unregistered_instances set to false
You can update the XML QoS as follow:
<datawriter_qos>
<writer_data_lifecycle>
<autodispose_unregistered_instances>
false
</autodispose_unregistered_instances>
</writer_data_lifecycle>
</datawriter_qos>
However, this is not for a topic but for a DataWriter.
Related
from the recent documentation, it seems, that Boost Log V2 has been extended with Text IPC message queue backend:
https://www.boost.org/doc/libs/1_80_0/libs/log/doc/html/log/detailed/sink_backends.html
but I haven't found any description, how can I configure it via .ini file:
https://www.boost.org/doc/libs/1_80_0/libs/log/doc/html/log/detailed/utilities.html#log.detailed.utilities.setup.settings_file
Can anybody help me, where are these settings documented?
Regards
There is no built-in factory for creating text IPC message queue sinks from settings. Mainly because the queue setup protocol, including choosing which process should create the queue, and with what parameters, is the application logic and not a configurable setting.
You can register a custom sink factory as described here (you don't need a custom sink as you can use the sink backend provided by Boost.Log). The sink factory should process the settings and create and configure the sink and the associated IPC queue accordingly.
I am running Celery+Kombu 4.4.6 on AWS SQS and want to revoke and terminate tasks.
Reading through documentation and SO posts, the transport needs to allow broadcast messages. SQS does not do broadcast messages and Celery+Kombu needs to use SimpleDB for those. That option was turned off by default long way back in version 1.x. To enables it, support_fanout = True needs to be added to the transport options.
But adding just that option is not working for me and I can't figure out what am I missing. Possible options are:
SimpleDB - it is not clear to me how do I even enable SimpleDB. I do see documentation in AWS, but I do not see it as a separate service.
Any additional config to be added?
Looking briefly at the SQS code, seems like SimpleDB is the only option for this. Is that correct?
Any other option to enable task revocation on SQS?
In my app.celery I have:
app = Celery('app',
broker=''sqs://<Access key>:<secret key>#')),
backend='cache+memcached://<host>:11211/')),
)
And in my app.settings I have:
CELERY_BROKER_URL='sqs://<access key>:<secret key>#'))
CELERY_BROKER_TRANSPORT_OPTIONS = {
'region': '<region>',
'supports_fanout': True,
}
CELERY_DEFAULT_QUEUE = 'app'
CELERY_DEFAULT_EXCHANGE = 'app'
CELERY_DEFAULT_ROUTING_KEY = 'app'
My final solution was to use Amazon MQ with a RabbitMQ instance. Amazon SimpleDB seems to be gone, making any support in Celery+Kombu obsolete and broken.
I've created a mule application with the following configuration to SQS. This lives in my config.xml file.
<sqs:config name="amazonSQSConfiguration" accessKey="${aws.sqs.accessKey}" secretKey="${aws.sqs.secretKey}" url="${aws.sqs.baseUrl}" region="${aws.account.region}" protocol="${aws.sqs.protocol}" doc:name="Amazon SQS: Configuration">
<reconnect count="5" frequency="1000"/>
</sqs:config>
This is problematic for me because when this SQS configuration loads up, it tries to connect to Amazon SQS queue but can't because access to the queue is not accessible from my machine.
For munit, unit purposes, I'm looking for a way to stop this from trying to connect on load?
Is there a way I can mock this sqs:config?
Please note this is different from mocking the connector in my flow? In this case I need to mock the config.
Or happy for any other suggestions.
thanks
We have deployed API-M 2.1 in a distributed way (each component, GW, TM, KM are running in their own Docker image) on top on DC/OS 1.9 ( Mesos ).
We have issues to get the gateway to enforce throttling policies (should it be subscription tiers or app-level policies). Here is what we have managed to define so far:
The Traffic Manager itself does it job : it receives the event streams, analyzes them on the fly and pushes an event onto the JMS topic throttledata
The Gateway reads the message properly.
So basically we have discarded a communication issue.
However we found two potential issues:
In the event which is pushed to the TM component, the value of the appTenant is null (instead of carbon.super)- We have a single tenant defined.
When the gateway receives the throttling message, it decides to let the message go thinking the "stopOnQuotaReach" is set to false, when it is set to true (we checked the value in the database).
Digging into the source code, we related those two issues to a single source: the value for both values above are read from the authContext and apparently incorrectly set. We are stuck and running out of ideas of things to try and would need some pointers to what could be a potential source of the problem and things to check.
Can somebody help please ?
Thanks- Isabelle.
Is there two TM with HA enabled available in the system?
If the TM is HA enabled, how gateways publish data to TM. Is it load balanced data publishing or failover data publishing to the TMs?
Did you follow below articles to configure the environment with respect to your deployment?
http://wso2.com/library/articles/2016/10/article-scalable-traffic-manager-deployment-patterns-for-wso2-api-manager-part-1/
http://wso2.com/library/articles/2016/10/article-scalable-traffic-manager-deployment-patterns-for-wso2-api-manager-part-2/
Is throttling completely not working in your environment?
Have you noticed any JMS connection related logs in gateways nodes?
In these tests, we have disabled HA to avoid possible complications. Neither subscription nor app throttling policies are working, both because parameters that should have values have not the adequate value (appTenant, stopOnQuotaReach).
Our scenario is far more basic. If we go with one instance of each component, it fails as Isabelle described. And the only thing we know is that both parameters come from the Authentication Context.
Thank you!
I am able to read the file from specified READFILEURI path if I can specify the poll interval.
My current requirement is to read the file from given path only when we trigger the proxy service.It should not poll the file automatically.When I click on "try this service" and send the request then only the file should read from the read file path and do processing.
TO test this I have removed the "transport.vfs.pollInterval" attribute from my proxy configuration and tested it.But file is not getting read from the path once I trigger the proxy request.
Could some one help me how to achieve this.
I guess it should work if you use the file connector.
https://docs.wso2.com/display/ESBCONNECTORS/Working+with+the+File+Connector
You should be able to create a simple proxy that get's triggered via http/https and the uses the above mentioned file connector read operation to read the file.
Unfortunately I cannot give you an exact example because we're still on an older esb version where this connector isn't available.
Hope that helps.
Regards
Martin