The IBM WAS8 allows changing the logging level at runtime via API.
How to do the same thing for IBM Liberty server without changing the server.xml?
I think this is possible via defining custom API, e.g. REST endpoint that will do this. Is the vendor recommended way to do it?
Liberty does not provide an API equivalent to change logging levels. You can make the change at runtime (no restart required) by directly changing the server.xml or by changing the server.xml through Admin Center's Server Config tool (available in WebSphere Liberty, but not Open Liberty). I mention the latter because Admin Center uses public APIs for everything including making changes to the server.xml which means you could technically make the same API calls to change the server.xml to include your logging changes at runtime.
However, the drawback with that approach is that you'd have to use the file transfer API to read the server.xml, then make appropriate changes to it, and then use file transfer API again to persist the changes.
If you'd like to see an API for changing log levels, I would recommend opening an RFE (https://developer.ibm.com/wasdev/help/submit-rfe/)
Related
We are trying to read the CCSID of a remote queue manager using IBMMQDotnetClient 9.2.5. We are on Windows and the queue manager can be on Windows, Linux, or z/OS.
We tried using MQQueueManager.CharacterSet/CodedCharsetId properties and MQQueueManager.Inquire. These return the local/system character set. This is not what we want.
We also tried using PCF commands. That works for a Linux and Windows queue manager (not z/OS one) but requires more authorizations from the application user, which is our MQ administration (rightly so) reluctant to provide.
In the old version of our product, we do this using the C API MQINQ - but that requires deploying related C libraries which we would now like to avoid.
At the moment, we are using a workaround that is equivalent to specifying the MQCCSID environment variable to override the CCSID. (In other words, we are aware of that environment variable and do not see it as a very good solution).
Does someone know of a better way to do what we want to do?
NB: for any IBM staff seeing this: I opened support cases, the last one is TS009748884 https://www.ibm.com/mysupport/s/case/5003p00002gNy21AAC/mq-c-and-net-libraries-give-different-results-when-inquiring-for-the-queue-manager-ccsid?language=en_US. In there, IBM support person recommended to ask in the MQ support community. They provided this link: https://developer.ibm.com/articles/mq-downloads/. From what I see on that page, the only place to ask questions is SO - hence I am here.
I understand that the official documentation recommends using NiFi with HTTPS, but it nonetheless contains a word for using NiFi under HTTP, like the nifi.web.http.port property.
Also, I'd like to incrementally incorporate and evolve the NiFi instance into our's current data infrastructure, starting with non-critical data pipelines. So, the TLS layer right now is not necessary and could add friction during the deployment phase. So, I decide to go on the HTTP path.
After changing some settings, I am able to access NiFi's GUI at http://localhost:8080/nifi but I find out that I cannot make any change to the Flow. Write operations, i.e POST / PUT / DELETE requests, are rejected by HTTP 403.
NiFi doc says:
And by monitoring the API traffic between the GUI and NiFi instance, I can confirm that the PermissionsEntity has both canRead:true and canWrite:true.
I used a containerized NiFi instance.
Has anyone also encounter similar problems?
The root canvas may have been set for the default single-user that NiFi 1.14 generates if it starts up without security configuration.
First thing to try is right-clicking on the canvas and granting yourself access if you can.
The second option: try (re)moving the flow.xml.gz, users.xml and authorizations.xml and then restarting Nifi. New files will be generated that may work better with anonymous access.
Either way, setting up security now will probably mean less friction down the road, not more. I strongly advise you to bite the bullet and get it set up securely.
I am working on a spring boot application in java. I have a case where I need to pick up some runtime configuration(which can change dynamically without any need of deployment or rebooting the app) and use it in all the classes further ahead. It basically stores all the plug and play configurations I want my app to support.
I have tried listener pattern but it doesn't seem to be the best option since I don't want that config to be listened by a few, rather I want that config to flow through whole of the code.
Is there an existing design pattern or a technique that is a standard for such activity?
Kindly suggest.
In general you need to store the application configuration externally and then listen to changes on that. How the change is notified depends on the runtime environment. For example cloud platforms may have separate decoupled notification systems, desktop application may want to implement a file change listener and so on.
This pattern is generally called Runtime Reconfiguration Pattern (see this link). In conclusion there is no magic that will apply the changes throughout your code, but you will need to listen for the changes and adjust the runtime behavior based on those.
Let's consider a situation, where multiple services relay on data that can change any time and should be updated in each microservice roughly at the same time - for example there is a list of supported languages or some common policies that could change one day and affect many services at once.
One solution that I could think of is to have another microservice that could hold that data and any service that needs current state can just ask for it. The drawback is that this data is not changing very frequently, asking by HTTP is not that cheap and there is a lot of traffic to this let's say global registry service. As it is not changing very often, many services could just cache the data - in order to not ask for it every time - and not be able to respond to change quick enough when the change is made to the configuration.
The other solution could be to externalize such configuration - in AWS for example there could be some configuration file on S3 that would be available for others. The drawback here is that there is no way (as far as I know) to track changes in such file and there is no way to add some logic for verification if changed value in configuration is correct (there is no typos and so on), etc.
So my question is how to handle global configuration/registry in microservice world so that there is little HTTP overhead, you can audit changes as well as introduce change at the same time in many services?
I will prefer the option 1. Apart from the HTTP overhead, this will also lead your system in an inconsistent state. Service 1 might be working on new values but service 2 will be on old.
Since this is a distributed system that we are talking about, I am willing to take a risk with availability.
Have a configuration service that allows you to plan your config changes. Instead of saying change the value of A from x to y, you say change from x to y at time t. This t allows you to consistently propagate changes to all your system.You need to put in effort to understand what the min value of t should be for you set of services, how will you make all services acknowledge the changes and make them at the right time and how will you manage the new services that come up in between.
Another approach is use Spring Cloud Config (or something similar). It ask the service to register with the centralised config service and make refresh call to all the services to update config. Limitation being not all configs could be refreshed and if you are behind the LB you still need to handle ways to make sure all instances gets updated.
Use Config Server( spring cloud config server) that will maintain centralized configurations, you need to make changes to config server related to configurations, each microservices will come on startup for configurations to config server, even after start up after certain interval of time microservices can come to config server for validating any change in configurations and update accordingly.
There are couple of ways to do it, a better way especially in prod is to use external Configuration Store Pattern.
You can save the configuration in external stores like Azure Key Vault or Azure App configuration
Find more details about Azure key vault here:
Azure key vault
5-Minute quickstarts of Azure key vault integration
If you absolutely must have a shared config, best decoupled architecture I've encountered is as follows:
You have a standalone Config Service, completely private to the outside world and can only be accessed through an internal network for your microservices
ON STARTUP: Microservices do a pull request from the Config Service of what is needed per service and is stored in memory. if it is unable to pull from Config Service do not allow it to start. Have Retry Mechanism on this front.
ON CHANGE of the Config Service: Publish an event to your messaging layer that will force services to update their respective configurations.
Caveats:
do not put time sensitive configurations here, since we are using asynchronous communications here (if you have time critical configs why are they shared in the first place, you might need to revisit)
you need to handle your own plumbing, retry mechanism, memory management etc etc.
I have a C# client application that connects to multiple servers. I noticed that it is necessary to use NetLimiter activated rules in order to make my client connect correctly with higher priority when there is so many traffic on the client computer.
I did not find any documents about how can I embed and make rules programmatically in this application. However, I read here that someone tried to use Netlimiter API but failed.
I read somewhere that I can write my own application that uses TC API of the Windows in here and mark DSCP to make priorities. But I reached to this problem before setting flow options of my C# application.
Please guide me with this issue.
Look here. Connect() and SetRule() are the only APIs available.
NetLimiter seems to be a COM object, so to use it from C# you need something like this:
dynamic myownlimiter = Activator.CreateInstance(Type.GetTypeFromProgID("NetLimiter.VirtualClient"));
myownlimiter.Connect("host", "port");
and then use SetRule() as described in the first link.