I'm trying to follow one example from the Java API documentation (http://download.oracle.com/javase/1.5.0/docs/api/java/lang/management/MemoryPoolMXBean.html#Notification) related to the UsageThreshold property of the Memory Pool Beans and notifications. My intention is to do something every time the pool overcomes the threshold. This is the sample code:
MemoryPoolMXBean remoteOldGenMemoryPool =
ManagementFactory.newPlatformMXBeanProxy(
jmxServer,
"java.lang:type=MemoryPool,name=PS Old Gen",
MemoryPoolMXBean.class);
class MyListener implements javax.management.NotificationListener {
public void handleNotification(Notification notification, Object handback) {
String notifType = notification.getType();
if (notifType.equals(MemoryNotificationInfo.MEMORY_THRESHOLD_EXCEEDED)) {
// Do Something
println "Threshold passed";
}
}
}
// Register MyListener with MemoryMXBean
MemoryMXBean remoteMemory =
ManagementFactory.newPlatformMXBeanProxy(
jmxServer,
ManagementFactory.MEMORY_MXBEAN_NAME,
MemoryMXBean.class);
NotificationEmitter emitter = remoteMemory as NotificationEmitter;
MyListener listener = new MyListener();
emitter.addNotificationListener(listener, null, null);
remoteOldGenMemoryPool.setUsageThreshold 500000000;
When I execute the code and connect to my JVM I can see the following:
Threshold passed
02-Feb-2011 16:30:00 ClientCommunicatorAdmin restart
WARNING: Failed to restart: java.io.IOException: Failed to get a RMI stub: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
java.net.SocketException: Connection reset]
02-Feb-2011 16:30:03 RMIConnector RMIClientCommunicatorAdmin-doStop
WARNING: Failed to call the method close():java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
java.net.SocketException: Connection reset
02-Feb-2011 16:30:03 ClientCommunicatorAdmin Checker-run
WARNING: Failed to check connection: java.net.SocketException: Connection reset
02-Feb-2011 16:30:03 ClientCommunicatorAdmin Checker-run
WARNING: stopping
For some reason (that I don't understand yet) the code is trying to restart the connection to JVM. Any ideas why this can be happening or how to prevent it? Am I doing somehing wrong?
Thanks
May be you can add a variable to the jmx enviroment, like this:
m.put("jmx.remote.x.client.connection.check.period", 0L);
But, what i have encountered is little different from this.
you can see : http://chainhou.iteye.com/blog/1906688.
Related
I'm trying to understand why this error occurs:
javax.net.ssl|WARNING|01|main|2021-07-04 12:08:30.668 CEST|SSLSocketImpl.java:497|SSLSocket duplex close failed (
"throwable" : {
java.net.SocketException: Socket is closed
at java.base/java.net.Socket.shutdownInput(Socket.java:1538)
at java.base/sun.security.ssl.BaseSSLSocketImpl.shutdownInput(BaseSSLSocketImpl.java:216)
at java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:751)
at java.base/sun.security.ssl.SSLSocketImpl.bruteForceCloseInput(SSLSocketImpl.java:701)
at java.base/sun.security.ssl.SSLSocketImpl.duplexCloseOutput(SSLSocketImpl.java:562)
at java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:486)
at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.close(SSLSocketImpl.java:1034)
at com.ibm.db2.jcc.t4.a0.j(a0.java:343)
at com.ibm.db2.jcc.t4.b.freeTransport_(b.java:5523)
at com.ibm.db2.jcc.t4.a.close_(a.java:455)
at com.ibm.db2.jcc.am.Agent.close(Agent.java:345)
at com.ibm.db2.jcc.t4.b.b(b.java:965)
at com.ibm.db2.jcc.t4.b.a(b.java:804)
at com.ibm.db2.jcc.t4.b.a(b.java:441)
at com.ibm.db2.jcc.t4.b.a(b.java:414)
at com.ibm.db2.jcc.t4.b.<init>(b.java:352)
at com.ibm.db2.jcc.DB2SimpleDataSource.getConnection(DB2SimpleDataSource.java:233)
at com.ibm.db2.jcc.DB2SimpleDataSource.getConnection(DB2SimpleDataSource.java:200)
at com.ibm.db2.jcc.DB2SimpleDataSource.getConnection(DB2SimpleDataSource.java:182)
at com.example.MainApplication.main(MainApplication.java:36)}
)
javax.net.ssl|ALL|01|main|2021-07-04 12:08:30.668 CEST|SSLSocketImpl.java:1217|Closing output stream
Exception in sql: com.ibm.db2.jcc.am.SqlNonTransientConnectionException
DB2 SQL Error: SQLCODE=-20157, SQLSTATE=08004, SQLERRMC=WEBADMIN;QUIESCE DATABASE;;, DRIVER=4.25.13
com.ibm.db2.jcc.am.SqlNonTransientConnectionException: DB2 SQL Error: SQLCODE=-20157, SQLSTATE=08004
The exception is thrown when I'm invoking getConnection() method of the DriverManager:
connection = DriverManager.getConnection(DB_URL, properties);
I'm using Java 11.0.11 from Oracle (non-OpenJDK).
Talk with your DBA team or whoever manages the database - you get this exception because someone (or some job) has put the database into a specific state that is used for maintenance activity.
Normally this is a temporary situation, and the database (or Db2-instance) needs to be brought back to normal mode by an unquiesce action, when the maintenance activity is completed. After the unquiesce action, your connection should complete as normal.
The SQLCODE (-20157) and SQLERRMC ( SQLERRMC=WEBADMIN;QUIESCE DATABASE;) that are in the message tell you the cause of this exception.
Lookup SQL20157N in the docs to get the detailed explanation.
I have an app that exposes Websocket/SockJS/Stomp server endpoints and would like to run a JUnit tests that runs client (Java STOMP client, also from Spring) against it, to test "sending" features.
I have a test like
public void measureSpeedWithWebsocket() throws Exception {
final Waiter subscribeWaiter = new Waiter();
new Thread(() -> {
// Prepare connection
WebsocketClient listener = new WebsocketClient("/mytopic/stomp");
try {
listener.connectAndSubscribe();
subscribeWaiter.resume();
} catch (Exception e) {
e.printStackTrace();
}
}).start();
subscribeWaiter.await(); // Wait for connection.
Here I made use of Waiter from https://github.com/jhalterman/concurrentunit, which effect is basically to delay main thread of the test till secondary thread call resume(). This is likely wrong, because Spring server that is running in the context has to react
I am getting the following error
[INFO ] 2017-02-03 12:36:12.402 [Thread-19] WebsocketClient - Listening
[INFO ] 2017-02-03 12:36:12.403 [Thread-19] WebsocketClient - Connecting to ws://localhost:8083/user...
2017-02-03 12:36:14.097 ERROR 9956 --- [ Thread-19] o.s.w.socket.sockjs.client.SockJsClient : Initial SockJS "Info" request to server failed, url=ws://localhost:8083/user
org.springframework.web.client.ResourceAccessException: I/O error on GET request for "http://localhost:8083/user/info": Connection refused: connect; nested exception is java.net.ConnectException: Connection refused: connect
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:633) ~[spring-web-4.3.3.RELEASE.jar:4.3.3.RELEASE]
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:595) ~[spring-web-4.3.3.RELEASE.jar:4.3.3.RELEASE]
at org.springframework.web.socket.sockjs.client.RestTemplateXhrTransport.executeInfoRequestInternal(RestTemplateXhrTransport.java:138) ~[spring-websocket-4.3.3.RELEASE.jar:4.3.3.RELEASE]
at org.springframework.web.socket.sockjs.client.AbstractXhrTransport.executeInfoRequest(AbstractXhrTransport.java:155) ~[spring-websocket-4.3.3.RELEASE.jar:4.3.3.RELEASE]
at org.springframework.web.socket.sockjs.client.SockJsClient.getServerInfo(SockJsClient.java:286) ~[spring-websocket-4.3.3.RELEASE.jar:4.3.3.RELEASE]
at org.springframework.web.socket.sockjs.client.SockJsClient.doHandshake(SockJsClient.java:254) ~[spring-websocket-4.3.3.RELEASE.jar:4.3.3.RELEASE]
at org.springframework.web.socket.messaging.WebSocketStompClient.connect(WebSocketStompClient.java:274) [spring-websocket-4.3.3.RELEASE.jar:4.3.3.RELEASE]
at org.springframework.web.socket.messaging.WebSocketStompClient.connect(WebSocketStompClient.java:255) [spring-websocket-4.3.3.RELEASE.jar:4.3.3.RELEASE]
(...)
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_74]
Caused by: java.net.ConnectException: Connection refused: connect
How I can possibly make a proper test that "self-connects" to the websocket offered by my Spring Boot application?
If you are using Spring Boot than you are a lucky one :).
Here is an example http://rafaelhz.github.io/testing-websockets/ how you can test the web sockets, which perfectly works in Spring Boot and can helps you a lot. I am trying to do the same in Spring MVC but unfortunately that doesn't work in Spring MVC.
I am getting this error:
com.netflix.hystrix.exception.HystrixRuntimeException:
getCatchmentsByAreaType timed-out and fallback failed.
When I try calling the same method though API it works. I don't know why!
I have set following properties in ZuulApplication:
hystrix.command.default.execution.timeout.enabled=false
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=2000000
hystrix.threadpool.default.coreSize=100
hystrix.threadpool.default.maxQueueSize=100
hystrix.threadpool.default.queueSizeRejectionThreshold=100
ribbon.IsSecured=true
ribbon.ConnectTimeout=2000000
ribbon.ReadTimeout=2000000
ribbon.maxAutoRetries=3
I am currently trying to connect to a MongoDB replica set using the (relatively) new 3.0 Java driver. However I can't seem to catch the MongoSecurityExceptions that occur when the user provides bad credentials. This is my current code.
try {
MongoClientURI mongoClientURI = new MongoClientURI("mongodb://<user>:<password>#member1.com:27017/?authSource=db"
this.mongoClient = new MongoClient(mongoClientURI);
}
catch(Exception e) {
// TODO: some proper exception handling
System.err.println(e.toLocalizedMessage());
}
This code works fine when run with correct credentials, but an exception is thrown outside of the try-catch when bad credentials are provided.
com.mongodb.MongoSecurityException: Exception authenticating MongoCredential{mechanism=null, userName='<user>', source='<source>', password=<hidden>, mechanismProperties={}}
at com.mongodb.connection.SaslAuthenticator.authenticate(SaslAuthenticator.java:61)
at com.mongodb.connection.DefaultAuthenticator.authenticate(DefaultAuthenticator.java:32)
at com.mongodb.connection.InternalStreamConnectionInitializer.authenticateAll(InternalStreamConnectionInitializer.java:99)
at com.mongodb.connection.InternalStreamConnectionInitializer.initialize(InternalStreamConnectionInitializer.java:44)
at com.mongodb.connection.InternalStreamConnection.open(InternalStreamConnection.java:115)
at com.mongodb.connection.DefaultServerMonitor$ServerMonitorRunnable.run(DefaultServerMonitor.java:127)
at java.lang.Thread.run(Thread.java:745)
Any idea where to handle authentication exceptions?
The MongoClient constructors do not throw any connectivity-related exceptions. Rather, they return immediately after starting one or more background threads that attempt to establish a connection and authenticate based on the provided credentials.
It's only when an application uses the MongoClient to perform some operation on the MongoDB server that an exception will be thrown. However, that exception is a generic timeout exception indicating that the driver failed to find a suitable server for the operation before the server selection timeout expires. For example:
MongoClient client = new MongoClient(asList(new ServerAddress("localhost"), new ServerAddress("localhost:27018")),
singletonList(MongoCredential.createCredential("username",
"admin",
"bad".toCharArray())),
MongoClientOptions.builder().serverSelectionTimeout(1000).build());
try {
client.getDB("admin").command("ping");
} catch (MongoTimeoutException e) {
// do something
}
will throw a MongoTimeoutException after 1 second. While no MongoSecurityException is thrown, the message of the MongoTimeoutException will contain relevant details. For example, when connecting to a three member replica set when one of the servers is down, and authentication failed on the remaining two, the message field of the MongoTimeoutException will be something like:
Timed out after 1000 ms while waiting for a server that matches
ReadPreferenceServerSelector{readPreference=primary}. Client view of
cluster state is {type=UNKNOWN, servers=[{address=localhost:27017,
type=UNKNOWN, state=CONNECTING,
exception={com.mongodb.MongoSocketOpenException: Exception opening
socket}, caused by {java.net.ConnectException: Connection refused}},
{address=localhost:27018, type=UNKNOWN, state=CONNECTING,
exception={com.mongodb.MongoSecurityException: Exception
authenticating MongoCredential{mechanism=null, userName='username',
source='admin', password=, mechanismProperties={}}}, caused by
{com.mongodb.MongoCommandException: Command failed with error 18:
'Authentication failed.' on server localhost:27018. The full response
is { "ok" : 0.0, "code" : 18, "errmsg" : "Authentication failed." }}}]
We are facing an issue in our production env. We have searched the net high and low and we were not able to come up with any answers.
This error(stacktrace below) occurs when an ejb lookup is made from managed server 1 to manager server 2. Virtual ip is used for the lookup. It occurs intermittently and at random intervals. We are not able to identify any pattern and If the ejb call is attempted two or three times, it gets through successfully.
Env details :
server : weblogic 10.0 MP1 running on java 1.5
os : solaris
Pls revert if any other details are required.
Source used for lookup :
private TreControlRemote getController() throws Exception {
Context context = null;
Properties p = new Properties();
TreControlHome treHome = null;
TreControlRemote remote = null;
ConfigurationLoader lAppLoader = null;
try {
mLog.debug("Entering");
lAppLoader = PropertiesFileLoader.getInstance("context.properties");
p.put(Context.INITIAL_CONTEXT_FACTORY, lAppLoader.getValue("INITIAL_CONTEXT_FACTORY"));
p.put(Context.PROVIDER_URL, lAppLoader.getValue("PROVIDER_URL"));
context = new InitialContext(p);
mLog.debug("context : " + context.getEnvironment());
remote = null;
treHome = (TreControlHome) context.lookup("CONTROL");
mLog.debug("Object --->>>>" + treHome);
remote = (TreControlRemote) treHome.create();
mLog.debug("Leaving");
} catch (Exception ex) {
mLog.fatal("Exception while getting remote", ex);
ex.printStackTrace();
throw ex;
} finally {
lAppLoader = null;
}
return remote;
}
The url is a virtual ip pointing to managed server 2 and it contains a ejb with jndi "CONTROL". The problem is that it successful on certain occassions and fails randomly with the error:
stack trace of the error :
*javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.StreamCorruptedException]
at weblogic.jndi.internal.ExceptionTranslator.toNamingException(ExceptionTranslator.java:74)
at weblogic.jndi.internal.WLContextImpl.translateException(WLContextImpl.java:426)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:382)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:367)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
```````````````````````````````````````````````````````````````````
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.StreamCorruptedException
at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:221)
at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:338)
at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:252)
at weblogic.jndi.internal.ServerNamingNode_1001_WLStub.lookup(Unknown Source)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:379)
... 33 more
Caused by: java.io.StreamCorruptedException
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1332)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:195)
at weblogic.rjvm.MsgAbbrevInputStream.readObject(MsgAbbrevInputStream.java:565)
at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:191)
at weblogic.jndi.internal.RootNamingNode_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:479)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:475)
at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:59)
at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:1016)
... 2 more*
Obtained the below mentioned stacktrace from the weblogic log. Could this error be related to our problem mentioned above?
*####<Aug 25, 2009 2:11:04 AM BST> <Info> <RJVM> <pkssv049> <M1AP4> <ACTIVE ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <1251162664181> <BEA-000513> <Failure in heartbeat trigger for RJVM: 5433424963141690658S:169.93.73.0:10040,10040,-1,-1,-1,-1,-1:pkssv049.***.net:10240,pkssv049.***.net:10241,pkssv050.***.net:10240,pkssv050.***.net:10241:LIQP1_LMSDomain:M1AP3
java.io.IOException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl#189ed0e - id: '5433424963141690658S:169.93.73.0:10040,10040,-1,-1,-1,-1,-1:pkssv049.***.net:10240,pkssv049.***.net:10241,pkssv050.***.net:10240,pkssv050.***.net:10241:LIQP1_LMSDomain:M1AP3' connect time: 'Mon Aug 24 20:24:02 BST 2009'' has already been shut down.
java.io.IOException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl#189ed0e - id: '5433424963141690658S:169.93.73.0:10040,10040,-1,-1,-1,-1,-1:pkssv049.***.net:10240,pkssv049.***.net:10241,pkssv050.***.net:10240,pkssv050.***.net:10241:LIQP1_LMSDomain:M1AP3' connect time: 'Mon Aug 24 20:24:02 BST 2009'' has already been shut down
at weblogic.rjvm.ConnectionManager.getOutputStream(ConnectionManager.java:1686)
at weblogic.rjvm.ConnectionManager.createHeartbeatMsg(ConnectionManager.java:1629)
at weblogic.rjvm.ConnectionManager.sendHeartbeatMsg(ConnectionManager.java:607)
at weblogic.rjvm.RJVMImpl$HeartbeatChecker.timerExpired(RJVMImpl.java:1540)
at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:464)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)*
Any help would be greatly appreciated.
Here is some additional info..
Is the problem intermittent, or does reproduce every single time? If the problem is intermittent, do you know what conditions it occurs under?
It occurs intermittently and we are not able to observe any pattern.
Are there any other errors/warnings logged either on the local server or on the remote server?
We see a lot of connection refused errors in the weblogic log
Are both the managed servers in the same domain?
Yes
when you pass an instance of com.myclientcompany.server.eai.interactionspecimpl as argument to
your ejb. the weblogic needs to deserialize(unmarshal) the object under the ejb context, and its needs the required class for unmarshalling. so if you include the interactionspecimpl class in your ejb-jar file, then you do not need to include those classes in your servers classpath
This issue can occur if you have either a Duplicate entry for or due to a blank space in between.
You need to check all the configuration files including the JDBC , JMS and the config.xml file to find such and entry.
Check if you have left a blank space while entering the JNDI name from the console as well.
Removing the blank space or removing the duplicate entry resolves this issue.