S
ske
Guest
> I would like to call asbman from the abl, something like input through value("asbman...") > But now I do not see a parameter for the adminserver password? Returning to the original question in this old thread, regarding how to supply the password to asbman even though there is no parameter for that: Have you tried submitting the password as data on the standard input to asbman? Use INPUT-OUTPUT THROUGH "asbman ...", and then PUT UNFORMATTED "mypassword". Or redirect a file containing the password within the command, "asbman ... < mypasswordfile". (If one of these do not work, the other might. This might perhaps also differ between Windows and Unix.) (Or submit the command on the same server where the appserver is running, so there will be no password prompt.) I realize this may not help you with the rest of the scenario that was described, since the -DirectConnect parameter is just supposed to bypass the nameserver and not the broker, as mentioned in previous replies. However, maybe it could allow some experimentation nonetheless, or help with other problems. Maybe it might be interesting to test what happens if you try to use -DirectConnect to connect to individual agents even though that is not the intended use for that parameter. Considering that in some operating modes, the client actually does talk directly to the agent after having been connected to one by the broker, maybe they're not so different anyway. But I realize there could be all sorts of details that would cause problems with this anyway. (I don't have the required environment readily at hand to experiment myself.) Another idea might be to just stop all agents and restart them, to force them to reload their temp-tables, if reloading them is such a big operation that it is worth it. On the other hand, if reloading the temp-tables really is such an expensive operation, then it seems to me that having to perform that operation in each and every one of the agents would result in a lot of expensive duplicate work amongst them. The more agents you have (to increase client throughput), the more duplicate work (slowing down that throughput). The total amount of work for reloading temp-tables would seem to be less with your current work-around where you cache the new dataset somewhere in the database (or anywhere you like), and compute it only once. Other than that, I would say a good improvement to AppServer, would indeed be to have some new way of broadcasting some calls to all running agents to inform them of global changes, and/or to have a way to specify an ABL procedure to run while waiting idly for the next client call, and/or of course some other good mechanism to share cache data between agents, which was also hoped for in some replies (did that never materialize?).
Continue reading...
Continue reading...