For testing purposes I try to run Netty 3.9.0 echo server example (can be found in Netty examples) inside Oracle database.
It starts correctly and I can see service running on port (with nmap), but whenever try to send message I get below exception:
java.net.SocketException: recv() failed, errno = 104
Connection reset by peer
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:33)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:198)
at sun.nio.ch.IOUtil.read(IOUtil.java:166)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:245)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:318)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
kgskupdbalance: time_used[58236668] greater than threshold[30000000] current_time[12380314910] time_start[12322078242]
Remarks:
Code works when run outside (in shell)
privileges are granted (and no other exception found)
My 1st suspect would be java.nio in database
Somebody has explanation ?
NOTE: Just to repeat, it's just for testing purposes.
Do not ask for motivation :-)
Thank you
It goes in zone which is not supported (native methods).
Related
I connected Talend to Autonomous Data Warehouse following the instructions supplied by Oracle, https://www.oracle.com/a/ocom/docs/database/talend-connection-adw.pdf
The connection seems to be successful, the studio builder is able to connect and run queries. But when we try to create a new job and add the connection, running the job returns the following error:
java.sql.SQLRecoverableException: IO Error: General SSLEngine problem, connect lapse 22 ms., Authentication lapse 0 ms.
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:794)
at oracle.jdbc.driver.PhysicalConnection.connect(PhysicalConnection.java:688)
at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:39)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:691)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:208)
at adw.test_0_1.test.tDBInput_1Process(test.java:337)
at adw.test_0_1.test.runJobInTOS(test.java:674) I ...
Anyone has ever seen this before?
This is a known problem with older jdbc drivers.
Download the latest ojdbc8.jar from https://www.oracle.com/database/technologies/appdev/jdbc-downloads.html is the best way to go.
(I cannot tell you offhand which version it started to work with and where exactly the problem was coming from, but it works with 19.10 and onwards for sure.)
I am getting the below error from jboss server when the load in the application is very high. When this error comes the application didnt process any request after a few times the connection resets and application resumes.
DEBUG Periodic recovery - first pass <Tue, 7 Feb 2017 13:01:59>
[Thread-12] [2017-02-07 13:01:59,029] DEBUG StatusModule: first pass
[Thread-12] [2017-02-07 13:01:59,029] DEBUG [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_3] - TORecoveryModule - first pass
[Thread-12] [2017-02-07 13:01:59,030] DEBUG [com.arjuna.ats.internal.jta.recovery.info.firstpass] Local XARecoveryModule - first pass
[Thread-12] [2017-02-07 13:02:09,030] DEBUG Periodic recovery - second pass <Tue, 7 Feb 2017 13:02:09>
[Thread-12] [2017-02-07 13:02:09,030] DEBUG AtomicActionRecoveryModule: Second pass
[Thread-12] [2017-02-07 13:02:09,030] DEBUG [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] - TORecoveryModule - second pass
[Thread-12] [2017-02-07 13:02:09,030] DEBUG [com.arjuna.ats.internal.jta.recovery`enter code here`.info.secondpass] Local XARecoveryModule - second pass
[Thread-12] [2017-02-07 13:02:09,030] DEBUG Recover java:/DefaultJMSProvider
[Thread-12] [2017-02-07 13:02:09,031] DEBUG ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.util.naming.Util.lookup(Util.java:222)
at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:393)
at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:339)
at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:261)
at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:108)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:773)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:665)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:200)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:799)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)
[Thread-12] [2017-02-07 13:02:09,031] DEBUG Cannot get delegate XAResource
javax.transaction.xa.XAException: Error trying to connect to provider java:/DefaultJMSProvider
at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:271)
at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:108)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:773)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:665)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:200)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:799)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)
Caused by: javax.naming.NameNotFoundException: XAConnectionFactory not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.util.naming.Util.lookup(Util.java:222)
at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:393)
at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:339)
at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:261)
after this below warning is also observed
WARN Destroying connection that is not valid, due to the following exception: oracle.jdbc.driver.T4CConnection#43017c6e
java.sql.SQLException: pingDatabase failed status=-2
at org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker.isValidConnection(OracleValidConnectionChecker.java:74)
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory.isValidConnection(BaseWrapperManagedConnectionFactory.java:560)
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkValid(BaseWrapperManagedConnection.java:323)
at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.matchManagedConnections(LocalManagedConnectionFactory.java:402)
at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:225)
at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:690)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:404)
at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:424)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:496)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
at com.infosys.fdc.util.ConnectionManager.getConnectionFromPool(ConnectionManager.java:382)
at com.infosys.fdc.util.ConnectionManager.getConnection(ConnectionManager.java:507)
at com.infosys.fdc.ejb.CommonEJBBean.execute(CommonEJBBean.java:165)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:233)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:100)
at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:84)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
at org.jboss.ejb.Container.invoke(Container.java:1092)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118)
at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
at org.jboss.proxy.ejb.SecurityContextInterceptor.invoke(SecurityContextInterceptor.java:64)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)
at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
at $Proxy125.execute(Unknown Source)
java.sql.SQLException: pingDatabase failed status=-2
This means there is "something" wrong with either the Oracle database itself or with the network.
pingDatabase is a method of oracle.jdbc.OracleConnection and is used by the JBoss OracleValidConnectionChecker to check if a connection to the database is still valid and working.
According to Oracle Database JBDC Driver API doc - Constant Field Values, the return codes are:
DATABASE_OK= 0; // The physical database connection is not closed and the database is reachable. (will not be logged)
DATABASE_CLOSED= -1; // The physical database connection is closed.
DATABASE_NOTOK= -2; // The physical database connection is not closed but the database is not reachable.
DATABASE_TIMEOUT= -3 // The call timed out before any positive or negative acknowledgement was received.
Test the network with the usual means like ping, telnet, ssh... connection tests.
Check if your DNS name resolution is working properly; use an IP address instead of a hostname when in doubt.
Test if connections to the Oracle database are working using the Oracle tnsping utility or with SQL*plus.
Note: requires a native Oracle client install.
JBoss is only reporting this error which is coming from the Oracle JDBC driver. The root cause will either be the Oracle database itself, or the network.
Upgrade the Oracle JDBC driver. We have seen many reports where this fixed the issue. It would seem that the older driver(s) had a bug which could cause return code "-2".
To get to the root cause, need to work with Oracle since this error is coming from the Oracle driver, and is only being reported by JBoss.
The error indicates that connectivity was not possible between the JBoss application server and the database
This is most likely due to a problem with the network or the database server itself. Sometimes, such issues are temporary, however, you will want to engage your network and/or DBA team to review the issue if this issue persists.
It is highly recommend reaching out to Oracle with the TRACE logs and getting input from them.
Computer science 101. Reduce the load on your server. My team has developed some demos to show the impact of large number of connections to your database, and you can see a video of it here: https://www.youtube.com/watch?v=XzN8Rp6glEo
When our application tries to connect Oracle database, this exception is thrown:
java.sql.SQLRecoverableException: Connection has been administratively disabled by console/admin command. Try later. java.lang.Exception: It was disabled at Tue Oct 20 23:55:14 CEST 2015
But, from Weblogic console the connection test returns OK.
Weblogic version: 12.1.3.0.0
Any explanation is welcome. Thanks
The reason the test works is because that is creating a connection and running a test query. That is not what your code is doing when it is using the data source in an ejb. The code is going through the connection pool and that is what has been marked as bad. There is no solution provided by Oracle that I have found except to: restart the server and that will re-enable the connection pool.
I suspect you have "Test connections on reserve" set because that is when this usually arises. What Weblogic does is: before it returns a connection from the pool it will run a test query, if the test query fails it waits and runs it one more time. If the query fails again it marks the connection as unhealthy. If all the connections in the pool become unhealthy it will mark the pool as disabled and gives you the error message you see: 'Connection has been administratively disabled by console/admin command. Try later.'
In regards to the 'Try Later' part of the error message, as far as I can tell Oracle is wrong about trying again later. I have never seen it recover later.
I'd like to share this article that help me out to understand better my problem:
https://www.techpaste.com/2012/09/connection-administratively-destroyed-reconnect-oracle-weblogic-server/
The “java.sql.SQLException: Connection has been administratively destroyed.” is expected:
the DB was shutdown; even if it was restarted later, the JDBC connection are pointing to DB processes
that have been destroyed.
You need to restart your WebLogic Server to recreate new JDBC connections.
All the current transactions are lost, as the database was shutdown.
High availability of your RDBMS is required to minimize this issue.
Is there any other error before that one ?
Maybe in the log you can find that connection is been closed.
You can avoid this by selecting "Test on Connection Reserve" in the datasource.
I have following situation:
there is some Jmeter test. I run it from different locations. I get below error for some requests.
org.apache.http.NoHttpResponseException', 'Non HTTP response message:
The target server failed to respond'
Error is not permanent, it happens from time to time.
The weird thing here is that for some location this error happened and for some not.
Jmeter configuration (jmeter.properties) is identical for all locations, however mentioned error occurred only for some of them.
I've searched regarding that error and find a post about problem with HttpClient4 (which is default for HttpSampler implementation).
When I change implementation to 'Java' - problem gone.
However I can't understand why does the test works from one location and failed from another. Does somebody have any ideas regarding that? The only idea I have is some kind of firewall that has some connections limitation from some specific address.
p.s. All URL that fails where accessible from all locations with the browser, if any.
Read this:
https://wiki.apache.org/jmeter/JMeterSocketClosed
It explains why issue happens with HTTP Client.
Browsers by default do stale check and retries which may explain why you don't reproduce in Browsers.
I was getting the same problem when trying to get a token from WSO2
org.apache.http.NoHttpResponseException: The target server failed to respond
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:61)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:481)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:298)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1105)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1094)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:429)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257)
at java.lang.Thread.run(Unknown Source)
Changing the Protocol to https worked for me.
I am facing a very strange problem.
I am using my application with RMI for 8 month in production but since a new (big) update I dont know what is wrong.
It is a server where 3 clients connect.
And when I am using only client with a certain method I can not find anything wrong especially because all other clients work perfectly.
Is there maybe with RMI any local "cache" which should be deleted otherwise I can't tell.
Here is the output of the client's console:
C:\Users\Claudia\Desktop>java -jar CLIENT_erp_auer_client_v0_8ASASADSD.jar
java.rmi.MarshalException: error marshalling arguments; nested exception is:
java.net.SocketException: Software caused connection abort: socket write error
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(Unknown Sou
rce)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(Unknown Source)
at $Proxy7.update(Unknown Source)
at client.entity_types.LieferscheinpositionService.aendereLieferscheinposition(
LieferscheinpositionService.java:60)
at client.lieferscheinverwaltung.TreeTableNEULieferschein.addLieferscheinpositi
onen(TreeTableNEULieferschein.java:912)
at client.lieferscheinverwaltung.TreeTableNEULieferschein.<init>(TreeTableNEULi
eferschein.java:204)
at client.lieferscheinverwaltung.LieferscheinErstellung.getTreeTableNeuLiefersc
hein(LieferscheinErstellung.java:916)
at client.lieferscheinverwaltung.LieferscheinErstellung.<init>(LieferscheinErst
ellung.java:773)
at client.lieferscheinverwaltung.LieferscheinManagement.openLieferschein(Liefer
scheinManagement.java:1055)
at client.lieferscheinverwaltung.LieferscheinManagement$9.mouseClicked(Liefersc
Thank you.