I googled a lot regarding the error message “password is not set” when testing a datasource in WebSphere (220.127.116.11), but I did not find a solution. A co-worker finally found a solution (by accident?).
While having the application JVMs running, I created a new JAAS-J2C authenticator (in my case the same login but a different password), and changed the datasource to use the new authenticator. I saved the config and synchronized it. The files config/cells/cellname/nodes/nodename/resources.xml and config/cells/cellname/security.xml showed that the changes arrived on the node. Testing the datasource connectivity fails now with:
DSRA8201W: DataSource Configuration: DSRA8040I: Failed to connect to the DataSource. Encountered java.sql.SQLException: The application server rejected the connection. (Password is not set.)DSRA0010E: SQL State = 08004, Error Code = ‑99,999.
Restarting the application JVMs does not help.
After stopping everything (application JVMs, nodeagent and deployment manager) and starting everything again, the connection test of the datasource works directly as expected.
I have not tested if it is enough to just stop all application JVMs on one node and the correspding nodeagent, or if I really have to stop the deployment manager too.
I counted 18 projects which are given to FreeBSD in this years GSoC. For 3 of them I have some comments.
Very interesting to me is the project which is named Collective limits on set of processes (a.k.a. jobs). This looks a bit like the Solaris contract/project IDs. If this project results in something which allows the userland to query which PID belongs to which set, than this allows some nice improvement for start scripts. For example at work on Solaris each application is a mix of several projects (apache = “name:web” project, tomcat = “name:app” project, Oracle DB = “name:ora” project). Our management framework (written by a co-worker) allows to easily do something with those projects, a “show” displays the prstat (similar to top) info just for processes which belong to the project, a “kill” sends a kill-signal to all processes of the project, and so on. We could do something similar with our start scripts by declaring a namespace (FreeBSD:base:XXX / FreeBSD:ports:XXX?) and maybe number space (depending on the implementation) as reserved and use it to see if processes which belong to a particular script are still running or kill them or whatever.
The other two projects I want to comment upon here are Complete libpkg and create new pkg tools and Complete Package support in the pkg_install tools and cleanup. Both projects reference libpkg in their description. I hope the mentors of both projects pay some attention to what is going on in the other project to not cause dependencies/clashes between the students.
That I do not mention other projects does not mean that they are not interesting or similar, it is just that I do not have to say something valuable about them…