Shutdown Hsqldb server when no more clients are connected - hsqldb

I start a hsqldb 1.8 server like this:
java -cp "%classpath%;.;Y:\PlantOperations\bldPlantOperations\code\lib\jboss\hsqldb-1.8.0-10.jar;C:\Documents and Settings\BThirup\Application Data\Rockwell Automation\FactoryTalk ProductionCentre\ProcessDesigner\hsqldb-1.8.0-10.jar;C:\Documents and Settings\BThirup\Application Data\Rockwell Automation\FactoryTalk ProductionCentre\ShopOperation\hsqldb-1.8.0-10.jar;" org.hsqldb.Server -database.0 file:"C:\Documents and Settings\BThirup\Application Data\Rockwell Automation\FactoryTalk ProductionCentre\logs\ApplicationLog\mydb" -dbname.0 xdb
I have multiple clients which connect(in no particular order) using jdbc:hsqldb:hsql://localhost/xdb;shutdown=true
I want to shutdown Hsqldb server when no more clients are connected.
I read in docs that adding shutdown=true as I have in jdbc url would cause hsqldb to shutdown after no more clients are connected. But I do not see that happening.
I also tried
Properties info = new Properties();
info.put("user", "SA");
info.put("password", "");
info.put("shutdown", "true");
conn = DriverManager.getConnection(dbString, info);
The above also does not cause hsqldb server to shutdown after the last client disconnects.
Any help on this is appreciated
Bala

The shutdown=true property works with the in-process connection, not via the server connection.
It may work if you add this property to the database URL in the server startup. This would cause the database to shutdown, which in turn would cause the server to shutdown.
java -cp ... org.hsqldb.Server -database.0 file:"C:\Documents and Settings\BThirup\Application Data\Rockwell Automation\FactoryTalk ProductionCentre\logs\ApplicationLog\mydb;shutdown=true" -dbname.0 xdb
Unrelated to this, you need only one reference to the hsqldb-1.8.0-10.jar in your classpath.

Related

JMX connection to Gemfire over SSL

I have used GFSH to start locator like below
start locator --name=gemfire_locator --security-properties-file="../config/gfsecurity.properties" --J=-Dgemfire.ssl-enabled-components=all --mcast-port=0 --J=-Dgemfire.jmx-manager-ssl=true
Also started server
start server --name=server1 --security-properties-file="../config/gfsecurity.properties" --J=-Dgemfire.ssl-enabled-components=all --mcast-port=0 --J=-Dgemfire.jmx-manager-ssl=true
I am trying to connect to Gemfire as ClientCache which works perfectly fine over SSL. But When I connect as JMX client, I am getting below error in Java code as well as Jconsole.
Error:
Exception in thread "main" java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: non-JRMP server at remote endpoint]
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:369)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
at SamplePlugin.main(SamplePlugin.java:101)
Am I missing any other configuration?
Here is my JAVA_TOOL_OPTIONS:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=true
-Djava.rmi.server.hostname=myhostname
You will also need to add the geode-core jar to your classpath for jvisualvm. Use the --cp:a option. I would suggest just using geode-dependencies.jar as that will get everything you might need.
The reason this is required is explained a bit in the comments for ContextAwareSSLRMIClientSocketFactory. Basically it seems that when RMI uses SSL, the necessary RMIClientSocketFactory is exported from the server to the client for use there. In general this would simply just be SslRMIClientSocketFactory. But in our case, we have a custom socket factory and so the client (jvisualvm in this case) needs to have access to it.

Websphere application server LDAP connection pool

We are using websphere application server 8.5.0.0. we have a requirement where we have to query a LDAP server to get the customer details. I tried to configure the connection pool as described here and here.
I passed the below JVM arguments
-Dcom.sun.jndi.ldap.connect.pool.maxsize=5
-Dcom.sun.jndi.ldap.connect.pool.timeout=60000
-Dcom.sun.jndi.ldap.connect.pool.debug=all
Below is a sample code snippet
Hashtable<String,String> env = new Hashtable<String,String>();
...
...
env.put("com.sun.jndi.ldap.connect.pool", "true");
env.put("com.sun.jndi.ldap.connect.timeout", "5000");
InitialDirContext c = new InitialDirContext(env);
...
...
c.close();
I have two issues here
When I am calling the service for the 6th time, I am getting javax.naming.ConnectionException: Timeout exceeded while waiting for a connection: 5000ms. I checked the connection pool debug logs and I noticed the connections are not returning back to the pool immediately despite closing the context safely in a finally block. The connections are released after some time and expired after sometime after the release. There after if I call the service again, it connects to the LDAP server but new connections are being created.
I tried to execute the code and I am able to see the connection pool debug logs. But the logs are being logged in System.Err log. Is this an issue? Can I ignore it?
But when I run the code as a standalone application(multithreaded with loop of 50 times), the connections are returned/released immediately.
Can anyone please let me know what am I doing wrong?

apache ignite - jdbc driver for sql query from cache gives GridClientConnectionResetException when run independently

apache ignite 1.7
i have loaded data in cache and ready to query from it.
when run independently using jdbc driver, it gives a
"GridClientConnectionResetException: Failed to perform request"
When i run the same along with the "pre-load cache" code, it runs ok.
Not sure what am i doing wrong here.
Class.forName("org.apache.ignite.IgniteJdbcDriver");
Connection conn =DriverManager.getConnection(jdbc:ignite://:/);
Statement stmt=conn.createStatement();
ResultSet rs = stmt.executeQuery("Select id,name from ...");
Also, if i use the jdbc:ignite:cfg://, it gives spring context resource is not injected error.
Its the same config used to preload data.
You should check the server node log. Most likely there is an exception that is causing the connection to be closed.

Mule ESB: Is it possible to start 2 instances of the Mule ESB

I created two sepaerate directories in which I installed the Standalone Mule ESB server:
/ee/mmc-distribution-mule-console-bundle-3.5.2-HF1
/ee2/mmc-distribution-mule-console-bundle-3.5.2-HF1
I start up the first server, and below is the status:
[root#x240perf2 mmc-distribution-mule-console-bundle-3.5.2-HF1]# ./status.sh
MMC is running as PID=1998.
Mule Enterprise Edition is running as PID=2619.
Then I try to start the second instance:
[root#x240perf2 mmc-distribution-mule-console-bundle-3.5.2-HF1]# ./startup.sh
Port 8585 is in use, please make it available and try again.
So apparently the port 8585 is being used by the original instnace
So I stop the first instnace, and start the second istance, which comes up successfully, as follows:
./startup.sh
Please enter the desired port for Mule [Default 7777]:
Starting MMC, please wait...
class com.sun.jersey.multipart.impl.MultiPartConfigProvider
class com.sun.jersey.multipart.impl.MultiPartReader
class com.sun.jersey.multipart.impl.MultiPartWriter
[11-13 16:49:19] WARN HttpSessionSecurityContextRepository [http-bio-8585-exec-1]: Failed to create a session, as response has been committed. Unable to store SecurityContext.
[11-13 16:49:32] WARN HttpMethodBase [http-bio-8585-exec-12]: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[11-13 16:49:38] WARN HttpSessionSecurityContextRepository [http-bio-8585-exec-12]: Failed to create a session, as response has been committed. Unable to store SecurityContext.
Nov 13, 2014 4:49:50 PM org.apache.catalina.core.StandardServer await
INFO: A valid shutdown command was received via the shutdown port. Stopping the Server instance.
Nov 13, 2014 4:49:50 PM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["http-bio-8585"]
But notice it seems to be using 8585 for tomcat (of which I know little about, except it some sort of app server, never used it)
I examined this site:
http://www.mulesoft.org/documentation/display/33X/Running+Multiple+Mule+Instances
but it does nto discuss the issue., and the page it points do does not seem current. Did I misunderstand something
Is it possible to run two separate instances of Mule ESB at the same time
and if so, how ? (how would I change the port its using, what file should I modify)
Thanks
Edit: my second post in response to answer:
(BTW: I am using Mule ESB standalone Enterprise Edition 3.5.2)
To make sure I did not have any apps that were running
on port 8585, I shutdown my original instance, and created two new instances, and made sure no apps were deployed to either instance.
I brought up the first instance without issue, but the second instance I brought up still gives me the port 8585 in use error (from startup.sh)
This site says that the MMC default port is 7777, but the tomcat default port on which it runs is 8585
http://www.mulesoft.org/documentation/display/current/Setting+Up+MMC-Mule+ESB+Communications
I used the following command to find all files within my second instance of por t 8585
find . -type f |xargs grep "8585
Other than log files I got two hits
startup.sh
and
/mmc-3.5.2-HF1/apache-tomcat-7.0.52/conf/server.xml
I did NOT find in either instance the $MULE_HOME/apps/mmc/mule-config.xml (probably because I have no apps deployed)
In the server.xml, the MMC apparently uses tomcat to
handle the MMC applicaiton, and server.xml contains
the following:
<Connector port="8585" protocol="HTTP/1.1"
So I guess I could change 8585 to 8586 at this point, but ...
The startup.sh has serveral (about 9 or 10) hardcode dreferences to 8585 to check that the MMC is running and take action if it is or is not running
So do I actually have to change the entire startup.sh to replace 8585 with 8586 i the second instance as well as change the server.xml port 8585 reference ?
Thanks
You can run as many instances as you want, as long they don't use the same ports. Looks like you are deploying something in port 8585, so in the second instance you have to select a different port.
Is that port being used in any application that you developed and deployed in the Mule runtime?
Also, if you are using the Mule runtime with the MMC agent activated, you also have to change the port for the agent in the second instance. I think you can do that in the /conf/wrapper.conf or by passing to the startup script the following parameter:
-Dmule.mmc.bind.port=7778
(or any port that is free).
You can run as many as you want.
In MMC we can able to deploy and run many applications each applications has its own instance

Naming a JMX connection when using --openjmx

I am using the Java Visual VM command line to open remote JMX connections. I use it like this:
jvisualvm.exe --userdir "user-config" --openjmx hostname:port
This works perfectly fine. But the connection name in the view shows as hostname:port. Is there any way I can pass a logical name to this connection? I can rename the connection from the view, but it doesn't stick when I reopen. I have about 10 connections from the same hostname, so wanted to logically separate out the individual connections.
Any ideas? It would even work if can just have the names stick in the user-config.
You can start your application with -Dvisualvm.display.name="Your_name" and your application will be named "Your_name" in VisualVM. See this and this feature requests for details. Note that you have to use VisualVM 1.3.4+ or Java VisualVM from JDK 7 Update 6 or newer.