I am trying to configure the Lock Manager instances for Oracle ATG 10.2 running on WebLogic 10.3.6 and was wondering if these instances absolutely need database connectivity? We plan to only run the ServerLockManager components on these servers and nothing else.
Thoughts?
In theory you may be able to create your own ATG module which only has your only server lock manager components defined and you could only startup that single module on your 'lock manager' weblogic instances. This would require quite a bit of customization to configuration and I have never seen it done across the handful of customers I have worked on, so it is not common and you will likely have some difficulties implementing and getting proper support from Oracle if you do have issues with repositories / lock managers in the future.
In any case, there is a chance that depending upon your repository and lock server configurations, the lock manager components you start up may have required dependencies on other components that ultimately have dependencies on DB based repositories. So, in the end you may likely require DB connectivity regardless.
Related
What is the gradle task to clear all modules in a MarkLogic database?
I have tried mlClearDatabase, but it didn't work.
mlClearDatabase will clear the content database.
The task that you are looking for to clear the modules database is:
mlClearModulesDatabase - if the application exists, clear its modules database; otherwise do nothing
If you are clearing the modules in order to ensure that you are deploying to a fresh modules database, then you might want to use mlReloadModules, which will invoke mlClearModules and then mlLoadModules.
https://github.com/marklogic-community/ml-gradle/wiki/Task-reference#modules
mlClearModulesDatabase
gradle doesn't gurantee complete Modules database cleanup if other App server has dependency on that Modules database
mlClearDatabase -Pdatabase={db-name} -Pconfirm=true
gradle will clear the said database in force mode, for that reason, -Pconfirm=true is used. If other App servers have dependency on the cleared Modules database, your application will fail.
It is very true that mlReloadModules is the right way to deploy/redeploy modules.
I am in the process of setting up SQ for a large organization. I plan to have two separate systems one for update testing and rule development. The second would be the production system where real work occurs. I will be using SQL 2014 typically when I do that I use a SQL always On group to sync to a DR server in another datacenter. My question is with a SonarQube instance does it make sense to DR the application to that level. If my organization can wait for a period of time to stand up a new server in a DR event would that be possible with a proper backup of the DB? Further if there were no backups of the DB what would be lost with a fresh new SonarQube server besides setup/config time? Is there historical value of code scans that would be lost or would the next scan of the code base have us right back to where we were in terms of critical issues found etc.?
Thanks for your replies.
All the data is stored in the database so using DR on the database is a good idea. You should make backup of the database and restoring the database is also a good solution (note that you should do backup of installed plugins).
If you loose the database, you will also loose all the configuration (quality profiles, credentials, etc.) and the history of the analyzed projects.
So to restore a SonarQube instance, you have to :
Restore the database
Restore SonarQube or install the same version
Restore the plugins (${SONAR_HOME}/extensions/plugins)
During the first start, the ES files (${SONAR_HOME}/data/es) will be regenerated and you're instance will then be up and running.
If you have commercial plugins or if you are working with large SonarQube instance you may contact the sales team to have support on this setup.
Disclaimer : I'm working at SonarSource
I am just wondering how Flyway deals with the fact that several dynos can try to run a database migration several times in a clustered environment such as Heroku thereby causing a conflict?
It seems Flyway uses locking in order to deal with this issue.
To quote the documentation:
Can multiple nodes migrate in parallel? Yes! Flyway uses the locking
technology of your database to coordinate multiple nodes. This ensures
that even if even multiple instances of your application attempt to
migrate the database at the same time, it still works. Cluster
configurations are fully supported.
This question explains a bit more how the locking behaviour works. It appears to acquire a lock on the Flyway schema table: select * from dbschema.schema_version for update which might cause problems for longer running migrations as the innodb_lock_wait_timeout setting might cause a timeout, at least in the case of MySQL.
I am here to get some expert advice on deploying applications to WebLogic Production Server.
Is it a best practice to use Admin Server Console for deploying and redeploying applications in production. Actually I am deploying to a cluster having two managed server instances.
I have encountered this issue while i am redeploying application in the production. When i am deleting existing .ear file and adding updated .ear file will put the updated .ear file into prepared state. I can not make it Active state using Admin Server Console. If i try it will through some exceptions. But after some time it automatically goes in to active state, but i don't know what is happening inside. Sometimes i restart the server to make it active. Could anybody explain me what is the procedure when deploying application and redeploying applications in weblogic
Thanks in advance for any Help...
Generally WLST (WebLogic Scripting Tool) is used to deploy the applications. Administration Console can also be used to deploy/upgrade the applications but if there are many environments that need to be upgraded then WLST (which works like a command line tool) is much better option.
Get an overview of WLST to know how to use it to deploy/undeploy/upgrade applications.
Check out "Understanding WebLogic Server Deployment" and the "Redeploying Applications in a Production Environment". There are different factors that affect redeployment of an application which you might be running into.
http://docs.oracle.com/cd/E23943_01/web.1111/e13702/understanding.htm#i1057116
http://docs.oracle.com/cd/E23943_01/web.1111/e13702/redeploy.htm#g1039635
Additionally, there is a WebLogic Plug-in for Maven in more recent WebLogic releases that you can use for deployments in conjunction with Maven.
I installed a java web service on a machine that accesses an Oracle DB via JDBC on the same network. The service was functioning fine for several months until this morning when I installed another applicaiton that access the database using ODP.NET. I'm trying to figure out what went wronge to cause the ORA-01017 exceptions that I'm getting. This generally means that the login credentials are invalid, but the login credentials haven't changed. I also verified it the service's log4j output that it is indeed still trying to connect to the DB correctly.
I realize I don't have much to go off of here, but I'm trying to figure out what other dependencies that. The web service came packaged with ojdbc14.jar, so that tells me that it targets java1.4, but presumably would work fine in later java versions. Not too sure about it working with later java versions, however, it was working fine until today.
Does OJDBC rely on tnsnames.ora. If it depends on how the service uses OJDBC, then I'm not sure which it is doing. I suppose it's possible I deleted the tnsnames.ora, but that is a bit of a longshot. I also tried manging Apache Tomcat (running on Win Server 2003 x64) to target different java jvm versions, but to no avail. It was initially targeting the default jvm.
Are there other dependencies that I've missed here, or any diagnostic measures I could try? THe same web service is running on another machine on the same network which I am pretty sure is configured exactly the same. Again, it was working on both machines until today, and is now just working on the one.
Tomcat targets JDK 7.
Looks like replacing ojdbc14.jar with ojdbc6_g.jar did the trick. No idea why it was the case only for 1 of the 2 machines. ojdbc6 targets JDK 6, but ojdbc14 did, and should have continued to work. If anyone has any additional insight here, let me know.