JDBC Adaper "socket closed"

Hello All,
We are trying to update a database table in Oracle through SAP XI.
Our scenario is IDOC to JDBC.
We are facing a problem during the JDBC connectivity between XI and Oracle.
In adapter monitoring the error saying that Java.sql.SQLException: IO Exception: "socket closed".
We are using XI 3.0 with Oracle 9.2 and at the other end the Database system(where the updation is to be done) is based on Oracle 8.1
The above process works when we try to update the database table (created on Oracle 8i) throgh JAVA Application.
When this updation occurs throgh XI it fails!!
Thanks in Adv.
Rajesh Yallabandi

Good day Yallabandi,
Can other SQL statment works?
If not then:
Please check that you supplied the JDBC adapter with the right and most updated matching JDB\CODBC driver for your destination database.
You also need to load the right jars to your Adapter framwork using the SDM tool.
Follow the "How To Install and configure JDBC" guide
supplied by SAP (get it on the service market place).
Good luck.
Nimrod Gisis
Message was edited by: Nimrod Gisis

Similar Messages

Socket closed exception

Hi all,
I am trying to execute an XI scenario in which i am sending data from sap R/3 system to a table in Oracle 8.0 system using JDBC adapter.
The XI server has JDBC 9.0 driver.
On sending the message, status shown on the XI server is successful, but no data is getting posted in the table.
In XI runtime workbench, in component monitoring, the error shown with the JDBC driver is SOCKET CLOSED.
Pls if anybody can help me with this problem.
Its very urgent.
Thanks in advance.
Regards
Neetu

Hi,
The error shown in the Adapter Monitor in Runtime Workbench is:
Receiver Adapter v1027 for Party '', Service 'HURES':
Configured at 16:35:07 2006-05-12
Last message processing started 15:16:02 2006-05-13, Error: Transform error in xml processor class, rollback:
ERROR:Processing request: Error when executing statement for table/stored proc. 'sap_promotion': java.sql.SQLException: Io exception: Socket closed
     at com.sap.aii.adapter.jdbc.xml2sql.service(xml2sql.java:175)
     at com.sap.aii.adapter.jdbc.XI2JDBC.onInternalMessage(XI2JDBC.java:266)
     at com.sap.aii.adapter.jdbc.SapAdapterServiceFrameImpl.callSapAdapter_i(SapAdapterServiceFrameImpl.java:170)
     at com.sap.aii.adapter.jdbc.SapAdapterServiceFrameImpl.callSapAdapter(SapAdapterServiceFrameImpl.java:146)
     at com.sap.aii.af.modules.CallAdapterWithMessageBean.process_receiver(CallAdapterWithMessageBean.java:206)
     at com.sap.aii.af.modules.CallAdapterWithMessageBean.process(CallAdapterWithMessageBean.java:161)
     at com.sap.aii.af.mp.module.ModuleLocalLocalObjectImpl1.process(ModuleLocalLocalObjectImpl1.java:103)
     at com.sap.aii.af.mp.ejb.ModuleProcessorBean.process(ModuleProcessorBean.java:221)
     at com.sap.aii.af.mp.processor.ModuleProcessorLocalLocalObjectImpl0.process(ModuleProcessorLocalLocalObjectImpl0.java:103)
     at com.sap.aii.af.listener.AFWListenerBean.onMessage(AFWListenerBean.java:216)
     at com.sap.aii.af.listener.AFWListenerLocalObjectImpl0.onMessage(AFWListenerLocalObjectImpl0.java:103)
     at com.sap.aii.af.ra.ms.impl.ServicesImpl.deliver(ServicesImpl.java:262)
     at com.sap.aii.adapter.xi.ms.XIEventHandler.onDeliver(XIEventHandler.java:611)
     at com.sap.aii.af.ra.ms.impl.core.queue.ReceiveConsumer.invokeHandler(ReceiveConsumer.java:353)
     at com.sap.aii.af.ra.ms.impl.core.queue.ReceiveConsumer.onMessage(ReceiveConsumer.java:98)
     at com.sap.aii.af.ra.ms.impl.core.queue.Queue.run(Queue.java:419)
     at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
     at java.security.AccessController.doPrivileged(Native Method)
     at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:94)
     at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:162)
Regards
Neetu

SQLException: Io exception: socket closed: Bad file number;

Hi,
My server application connects oracle 8i using thin driver.
My code opens a connection and create a statement object:
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Connection connection = DriverManager.getConnection(url, username, password);
connection.setAutoCommit(false);
Statement statement = connection.createStatement();
After a few hours it runs just fine I get the following error:
java.sql.SQLException: Io exception: socket closed: Bad file number;
The code line that couses this exception is:
statement.executeQuery("my SQL query");
after this there are more errors:
;java.sql.SQLException: Protocol violation;
(in code line: connection.execCommit())
and than a repeated exception of :
java.sql.SQLException: Io exception: Broken pipe;
Does anyone knows a solution? (is the problem in my code or in the oracle account?)
Thank!!!

Which package you are using? if you don't have
classes12.zip, try again by including that package in
the classpath. If you are already using classes12.zip
then try by including nls_charset12.zip in the
classpath.
You can get these packages in Oracle (otn) website.
SudhaThanks!
I had classes12.zip in my classpath, but my classpath also had: classes111.zip
so i removed classes111.zip from the classpath and as far as now,
the problem did not occur again!
(i also added nls_charset12.zip just to be sure)
Lilach

Remote desktop connection manager on windows 8.1, can't connect to windows server 2012 R2, Socket closed

remote desktop connection manager on windows 8.1, can't connect to windows server 2012 R2, Socket closed each time i try to open remote connection to the server,
does remote desktop connection manager V2.2 not compatible with windows 8.1, and if so, is there are any other compatible versions
or what's the problem,
Mahmoud Sabry IT System Engineer

this issue maybe will be fix by latest version, we still waiting for it
maybe your issue can be fix using this methods
https://social.technet.microsoft.com/Forums/windowsserver/en-US/61f218a5-5ef8-49da-a035-90cdd64fc9a0/problem-with-remote-desktop-connection-manager-error-3334?forum=winserverTS
http://shawn.meunier.com/?p=1#comment-43

JCOM on WLS 8.1 - SocketException: Socket closed

After creating my application and accessing it - if I don't use it for a while
I get the following exception when I access it. Other than creating a timer to
ping it every 10 seconds or so - is there some way to keep the socket open?
- Mike Reiche
java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
at java.net.SocketOutputStream.write(SocketOutputStream.java:124)
at com.linar.jintegra.RpcConnectionHandler.send(RpcConnectionHandler.java:272)
at com.linar.jintegra.Rpc.invoke(Rpc.java:239)
at com.linar.jintegra.RemObjectExporter.invoke(RemObjectExporter.java:346)
at com.linar.jintegra.StdObjRef.invoke(StdObjRef.java:57)
at com.linar.jintegra.Dispatch.vtblInvoke(Dispatch.java:763)
at excel._ApplicationProxy.getDefaultFilePath(_ApplicationProxy.java:1938)
at excel.Application.getDefaultFilePath(Application.java:2237)

Has anyone gotten an answer on this error? I also get a Socket Closed IOException
after a couple of minutes of not communicating to a remote DCOM application.
I also have to restart Weblogic to get it to communicate again. Works great as
long as I make a request every 10 or 20 seconds.
Rick Holland
>
I am having this exact same problem. I have a support case opened with
BEA about
it, and will let you know if I come up with a solution...
In my case, however, I am gonna have a very hard time sending BEA a repeatable
testcase that demonstrates this problem, as I access a DCOM app that
I cant redistribute.
Would your code be something that you can share with BEA? If so, that
would be
of tremendous help.
"Mike Reiche" <mreiche@no_spam.com> wrote:
After creating my application and accessing it - if I don't use it for
a while
I get the following exception when I access it. Other than creating
a timer to
ping it every 10 seconds or so - is there some way to keep the socket
open?
- Mike Reiche
java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
at java.net.SocketOutputStream.write(SocketOutputStream.java:124)
at com.linar.jintegra.RpcConnectionHandler.send(RpcConnectionHandler.java:272)
at com.linar.jintegra.Rpc.invoke(Rpc.java:239)
at com.linar.jintegra.RemObjectExporter.invoke(RemObjectExporter.java:346)
at com.linar.jintegra.StdObjRef.invoke(StdObjRef.java:57)
at com.linar.jintegra.Dispatch.vtblInvoke(Dispatch.java:763)
at excel._ApplicationProxy.getDefaultFilePath(_ApplicationProxy.java:1938)
at excel.Application.getDefaultFilePath(Application.java:2237)

Error on content write: Socket closed

Since a week or so we are getting the following stack trace on our WebCenter Portal (11.1.1.6.3). There are several content presenters on it, and so far I've not found out yet where the problem originates from. Has anyone experienced the same, or perhaps any pointers?
<Aug 24, 2012 3:10:13 PM CEST> <Error> <oracle.webcenter.content.internal.http.HttpServiceImpl> <WCS-11001> <Error on content write: Socket closed
oracle.webcenter.content.internal.http.InternalServerErrorException: Aug 24, 2012 3:10:13 PM oracle.webcenter.content.internal.http.HttpServiceExceptionFactory getException
ALL: Error on content write: Socket closed
at oracle.webcenter.content.internal.http.HttpServiceExceptionFactory.getException(HttpServiceExceptionFactory.java:191)
at oracle.webcenter.content.internal.http.HttpServiceExceptionFactory.createInternalServerError(HttpServiceExceptionFactory.java:707)
at oracle.webcenter.content.internal.http.HttpServiceExceptionFactory.createInternalServerError(HttpServiceExceptionFactory.java:685)
at oracle.webcenter.content.internal.http.HttpServiceExceptionFactory.createInternalServerError(HttpServiceExceptionFactory.java:664)
at oracle.webcenter.content.internal.http.Entity.sendResponse(Entity.java:205)
at oracle.webcenter.content.internal.http.HttpServiceImpl.doGetOrHead(HttpServiceImpl.java:322)
at oracle.webcenter.content.internal.http.HttpServiceImpl.service(HttpServiceImpl.java:179)
at oracle.webcenter.content.http.GetHandlerServlet.service(GetHandlerServlet.java:225)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.adf.share.http.ServletADFFilter.doFilter(ServletADFFilter.java:62)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.wcps.client.PersonalizationFilter.doFilter(PersonalizationFilter.java:75)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.webcenter.content.integration.servlets.ContentServletFilter.doFilter(ContentServletFilter.java:168)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.adf.share.http.ServletADFFilter.doFilter(ServletADFFilter.java:62)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.adf.library.webapp.LibraryFilter.doFilter(LibraryFilter.java:179)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442)
at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103)
at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171)
at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:139)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3730)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3696)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2273)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1490)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
>

We have a content presenter which loads a video file from the content server. It looks like the socket is unexpectedly closed at some point if the video is paused or stopped for some reason.

JSSE causes OSB business services to receive Socket Closed

Using WL 10.3.3 & OSB 11gR1 on jrockit 1.6.0_45 Redhat:
After enabling the "Use JSSE SSL" option in the managed servers's SSL tab ( because web service clients want to use SHA256 certificates ), OSB business services ( outbound to service providers ) fail with
Exception - Body: <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Fault xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<faultcode>BEA-380000</faultcode>
<faultstring>General runtime error: socket closed</faultstring>
After a lot of debugging, I've found that the Connection Timeout option within the OSB HTTP transport is involved.
OSB business services which use https AND have a non-zero value for HTTP transport's Connection timeout cause the Socket Closed error.
Business services which do not use HTTPS or do not have a Connection Timeout do not receive the error.
While setting the Connection Timeout to 0 allows the transaction to succeed, that leaves the OSB server vulnerable when the service provider host is not available.
So I've reset the Connection Timeout values to 0, and added this JVM parameter to each OSB managed server
-Dweblogic.http.client.defaultConnectTimeout=5000

There are few BUGs reported for similar issues.
OSB Server Showing "java.io.IOException: SSLEngine is closed" When Attempting to Connect to an External Web Service Using Two-Way SSL (Doc ID 1465618.1)

Socket Closed error please help us finding a fix for the same

Hi everyone,
I have a web application deployed on Weblogic 10.3.4.0. In the application there is hyperlink to download a resouce (say an PDF document). Upon clicking the link, IE shows the Open/Save/Cancel dialog box. If the Open/Save/Cancel dialog box is not acted upon by the user within 1 min after it pops up, Weblogic is closing the socket. This causes IE to only download a part of the file say 784 KB or something. Whereas the entire file maybe 1MB in size. Please help in fixing this issue ASAP.
Thanks in Advance
java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at weblogic.servlet.internal.ChunkOutput.writeChunkTransfer(ChunkOutput.java:525)
at weblogic.servlet.internal.ChunkOutput.writeChunks(ChunkOutput.java:504)
at weblogic.servlet.internal.ChunkOutput.flush(ChunkOutput.java:382)
at weblogic.servlet.internal.CharsetChunkOutput.flush(CharsetChunkOutput.java:249)
at weblogic.servlet.internal.ChunkOutput.checkForFlush(ChunkOutput.java:469)
at weblogic.servlet.internal.CharsetChunkOutput.implWrite(CharsetChunkOutput.java:396)
at weblogic.servlet.internal.CharsetChunkOutput.write(CharsetChunkOutput.java:198)
at weblogic.servlet.internal.ChunkOutputWrapper.write(ChunkOutputWrapper.java:139)
at weblogic.servlet.internal.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:169)
at com.teja.systemi.util.AroundData.copyStream(AroundData.java:311)
at com.teja.systemi.client.servlet.servant.Newdownloadsingle.producePageData(Newdownloadsingle.java:108)
at com.teja.systemi.client.servlet.servant.BaseViewController.serve(BaseViewController.java:542)
at com.teja.systemi.client.servlet.FrontController.doRequest(FrontController.java:226)
at com.teja.systemi.client.servlet.FrontController.doPost(FrontController.java:128)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3498)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Edited by: 910597 on Jan 27, 2012 2:15 AM

What do you mean by "moo" ?
Huh? You don't know about the moo? Are you livin' in a barn or sumthin'
Sorry, corny joke.
Seriously--if you haven't heard about the moo, then check out the MacBook forums. Nearly every third or fourth post is about the mooing problem.
My own MacBook moos, but it's not so bad that it makes me upset. I understand, though, that others have it much worse.
Black Macbook; Mini 1.5GHz (Late 2005); Mini 1.4GHz; PB G4 1GHz; PB Lombard; PB 2400; PMac G3; Blueberry iMac; iPod nano 4GB; and a talking Bill King bobblehead doll--Holy Toledo!

Lot of cursors hanging even the jdbc connection are closed

We use tomcat and thin oracle driver for out application. But we found lot of cursors hanging even the jdbc connection are closed.
We use a connection pool to manage the connections.

after properly closing the connections ,try to set all the Connection objects and ResulSet objects to null (force to null) , most likely these inactive sessions will dissapear.
might be a java garbage collection issue?
anyhow. I managed to get most of these inactive sessions to disappear. although I am using a Servlet. some of them are still not closed
Regards

New root certificates cause socket closed error

We have planning 9.3.1 services with ldap authentication. When we replaced our root certificates in dev we began getting errors. Mostly everything works, but after some inactivity a good log in will be flagged as an invalid user and throw the following exceptions:
2010-03-29 07:43:48,141 [[ORB=_it_orb_id_1,Pool=1]::id-3] WARN com.hyperion.css.spi.impl.ldap.LDAPProvider.authenticate(Unknown Source) - javax.naming.ServiceUnavailableException: ldaps.lirr.org:636; socket closed; remaining name ''
2010-03-29 07:43:48,141 [[ORB=_it_orb_id_1,Pool=1]::id-3] WARN com.hyperion.css.CSSAPIImpl.authenticate(Unknown Source) - com.hyperion.css.CSSAuthenticationException: Failed to authenticate user tlbarat against provider Novel1 Error Code: 2
NestedException:
javax.naming.ServiceUnavailableException: ldaps.lirr.org:636; socket closed; remaining name ''
Does anyone know what we could be doing wrong? We changed to a load balanced virtual server. Could this have caused our issue? We tried setting java option -Dsun.net.inetaddr.ttl=0 but it didn't work. We need to move the change to prod next week. Any insight would be appreciated.

The socket is being closed by the receiver, since it feels that the end of HTTP body stream has been reached. This could happen due to a number of reasons and cannot be directly discerened from your code.
Does changing the buffer size help?
Ironluca

ObjectIsClosedException: SAP DBTech JDBC: Object is closed

Hi everybody,
i try to insert data via jdbc in a loop (a Thread) with a PreparedStatement.
the first insertion is successful - but all following inserts are not because of
ObjectIsClosedException (see jdbc-traces)
I do not close the PrepearedStatement or the Connection.
What is the cause of the "[T166].close()" (see trace #2) ???
the Problem is with a call DBROC ({call INSERTEVENTENTRY(?,?,?,?,?,?,?,?,?,?,?,?,?,?)}, too!!
Thanks for your help!
Matthias
(MaxDB is running on SuSE Linux 11.1)
JDBC-Trace: #1
===========================
ClassLoader: sun.misc.Launcher$AppClassLoader at 1a16869
package com.sap.dbtech.jdbc, MaxDB JDBC Driver, SAP AG, 7.6.06 Build 002-000-008-537 (Make-Version: 7.7.06 Build 009-121-202-944) on Java 1.6.0_10
Thread a8c488 main Timestamp: 2009-05-15 13:06:58.792
new Connection 'jdbc:sapdb://xxxxxxxxxxEVENTDB'
user=eventhist
password=***
connectiontrace=/home/ighjhgj/workspace/EventLogger/jd...
Reject GSS Authentication - password is not empty
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000]
Thread 1431340 Thread-3 Timestamp: 2009-05-15 13:07:41.02
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setTimestamp (1, 2009-05-15 12:39:12.175)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setShort (2, 2)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setShort (3, 0)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setShort (4, -1)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setString (5, Biologie 2)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setString (6, 01GD61)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setString (7, aus)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setString (8, Nährstoffpumpe Gaswäsche)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setString (9, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setString (10, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setString (11, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setString (12, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setString (13, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].setString (14, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[T141][ParseID 000002440000090154000000].executeUpdate ()
new RTEException: -708 Timeout
whereAmIjava.lang.Throwable
 at com.sap.dbtech.util.Tracer.whereAmI(Tracer.java:328)
 at com.sap.dbtech.rte.comm.RTEException. 0
com.sap.dbtech.jdbc.ConnectionSapDB at 166aa18[T142].commit ()
com.sap.dbtech.jdbc.ConnectionSapDB at 166aa18[T142].close ()
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[closed][ParseID 000002450000060154000000].setTimestamp (1, 2009-05-15 13:07:35.886)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[closed][ParseID 000002450000060154000000].setShort (2, 1)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[closed][ParseID 000002450000060154000000].setShort (3, 1)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[closed][ParseID 000002450000060154000000].setShort (4, 1)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[closed][ParseID 000002450000060154000000].setString (5, Biologie 2)
<-!
Timestamp: 2009-05-15 13:07:41.111com.sap.dbtech.jdbc.exceptions.ObjectIsClosedException: SAP DBTech JDBC: Object is closed.
 at com.sap.dbtech.jdbc.ConnectionItem.assertOpen(ConnectionItem.java:53)
 at com.sap.dbtech.jdbc.CallableStatementSapDB.setString(CallableStatementSapDB.java:2191)
 at com.sap.dbtech.jdbc.trace.log.PreparedStatement.setString(PreparedStatement.java:704)
 at com.sap.dbtech.jdbc.trace.PreparedStatement.setString(PreparedStatement.java:336)
 at de.pkv.eventlogger.handler.EventLogEntryDAO.insertEventLogEntry(EventLogEntryDAO.java:141)
 at de.pkv.eventlogger.handler.DBhistoryOutputHandler.run(DBhistoryOutputHandler.java:50)
 at java.lang.Thread.run(Thread.java:619)
com.sap.dbtech.jdbc.ConnectionSapDB at 166aa18.close ()
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[closed][ParseID 000002450000060154000000].setTimestamp (1, 2009-05-15 13:07:36.046)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[closed][ParseID 000002450000060154000000].setShort (2, 2)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[closed][ParseID 000002450000060154000000].setShort (3, 0)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[closed][ParseID 000002450000060154000000].setShort (4, -1)
com.sap.dbtech.jdbc.CallableStatementSapDB at 17ce4e7[closed][ParseID 000002450000060154000000].setString (5, Biologie 2)
<-!
Timestamp: 2009-05-15 13:07:41.119com.sap.dbtech.jdbc.exceptions.ObjectIsClosedException: SAP DBTech JDBC: Object is closed.
 at com.sap.dbtech.jdbc.ConnectionItem.assertOpen(ConnectionItem.java:53)
 at com.sap.dbtech.jdbc.CallableStatementSapDB.setString(CallableStatementSapDB.java:2191)
 at com.sap.dbtech.jdbc.trace.log.PreparedStatement.setString(PreparedStatement.java:704)
 at com.sap.dbtech.jdbc.trace.PreparedStatement.setString(PreparedStatement.java:336)
 at de.pkv.eventlogger.handler.EventLogEntryDAO.insertEventLogEntry(EventLogEntryDAO.java:141)
 at de.pkv.eventlogger.handler.DBhistoryOutputHandler.run(DBhistoryOutputHandler.java:50)
 at java.lang.Thread.run(Thread.java:619)
JDBC-Trace: #2
===========================
ClassLoader: sun.misc.Launcher$AppClassLoader at 1a16869
package com.sap.dbtech.jdbc, MaxDB JDBC Driver, SAP AG, 7.6.06 Build 002-000-008-537 (Make-Version: 7.7.06 Build 009-121-202-944) on Java 1.6.0_10
Thread a8c488 main Timestamp: 2009-05-15 22:48:58.594
new Connection 'jdbc:sapdb://xxxxxxx/EVENTDB'
user=eventhist
password=***
connectiontrace=/home/mlbbl/workspace/EventLogger/jd...
Reject GSS Authentication - password is not empty
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00]
Thread e45076 Thread-3 Timestamp: 2009-05-15 22:49:15.555
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setTimestamp (1, 2009-05-15 22:48:26.031)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setShort (2, 6)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setShort (3, 0)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setShort (4, -1)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setString (5, KM2 Konstt)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setString (6, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setString (7, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setString (8, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setString (9, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setString (10, KM2)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setString (11, DCT1_XDC8:0)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setString (12, S24VD20.ACK)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setString (13, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].setString (14, null)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[T166][ParseID 0000026800000a0212003c00].execute ()
=> false
com.sap.dbtech.jdbc.ConnectionSapDB at 166aa18[T166].close ()
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[closed][ParseID 0000026800000a0212003c00].setTimestamp (1, 2009-05-15 22:48:26.021)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[closed][ParseID 0000026800000a0212003c00].setShort (2, 1)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[closed][ParseID 0000026800000a0212003c00].setShort (3, 1)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[closed][ParseID 0000026800000a0212003c00].setShort (4, 1)
com.sap.dbtech.jdbc.CallableStatementSapDB at 1c0e45a[closed][ParseID 0000026800000a0212003c00].setString (5, KM2 Konstt)
<-!
Timestamp: 2009-05-15 22:49:15.692com.sap.dbtech.jdbc.exceptions.ObjectIsClosedException: SAP DBTech JDBC: Object is closed.
 at com.sap.dbtech.jdbc.ConnectionItem.assertOpen(ConnectionItem.java:53)
 at com.sap.dbtech.jdbc.CallableStatementSapDB.setString(CallableStatementSapDB.java:2191)
 at com.sap.dbtech.jdbc.trace.log.CallableStatement.setString(CallableStatement.java:2888)
 at com.sap.dbtech.jdbc.trace.CallableStatement.setString(CallableStatement.java:1050)
 at de.pkv.eventlogger.handler.EventLogEntryDAO.callInsertEventLogEntry(EventLogEntryDAO.java:150)
 at de.pkv.eventlogger.handler.DBhistoryOutputHandler.run(DBhistoryOutputHandler.java:52)
 at java.lang.Thread.run(Thread.java:619)

it was the wrong place for a finally-statement in run()-Method:
 public void run() {
 while (true) { // do forever
 try {
 entry = this.theQueue.take(); // wait, if empty
 if (DEBUG) System.out.println(name + ": try to take from queue: " + entry);
 if (DEBUG) System.out.println(name + ": EventLogEntry: " + entry.toString());
 // do the work: insert into Database:
 success = dao.insertEventLogEntry(entry); // insert new Entry (Prep.Statement)
 //success = dao.callInsertEventLogEntry(entry); // insert new Entry (call db_proc)
 if (DEBUG) System.out.println(name + ": Insert new LogEntry. Success: " + success);
 // Thread.sleep(10);
 //Thread.yield();
 } catch (InterruptedException e) {
 System.err.println(name + ": Error in Thread.sleep()");
 e.printStackTrace();
 } catch (Exception e) {
 System.err.println(name + ": Error: " + e.getMessage());
 } // catch
 // finally {
 // if (con != null) {
 // try {
 // con.close();
 // } catch (SQLException e) {
 // // TODO Auto-generated catch block
 // e.printStackTrace();
 // } // if con
 // } // finally
 } // while
 } // run
regards
Matthias

InitialDirContext Throwing ServiceUnavailableException socket closed

Any assistance is appreciated.
Problems occurring when multiple DirContext instances are created. Attempting to make a SSL connection to Active Directory on port 636. A single successful context can be established in the below code. However, a second instantiation of InitialDirContext(env) results in a javax.naming.ServiceUnavailableException: [domain]:636; socket closed error. Multiple contexts are desired to establish a connection pool.
A few items to note. Establishing four unsecure DirContext on port 389 works successfully. I can establish a DirContext on port 636, use the context, close the context then establish new contexts without a problem. A server certificate was imported to the C:\j2sdk1.4.2_11\jre\lib\security\cacerts file. Testing on a local computer. Below is sample code:
public static void main(String[] args) {
 try {
 System.setProperty("javax.net.debug","all");
 // Set up the environment for creating the initial context
 Hashtable env = new Hashtable();
 env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
 env.put(Context.SECURITY_PRINCIPAL, "[USER DN]");
 env.put(Context.SECURITY_CREDENTIALS, "[PWD]");
 //NON SSL
 //env.put(Context.PROVIDER_URL, "ldap://[server]:389");
 //SSL
 env.put(Context.PROVIDER_URL, "ldap://[server]:636");
 env.put(Context.SECURITY_PROTOCOL, "ssl");
 env.put(Context.SECURITY_AUTHENTICATION, "simple");
 // Create the initial context
 DirContext ctx = null;
 DirContext ctx2 = null;
 DirContext ctx3 = null;
 DirContext ctx4 = null;
 try {
 //Works every time...
 ctx = new InitialDirContext(env);
 } catch (NamingException e) {
 e.printStackTrace();
 try {
 //Fails on port 636, works on port 389
 ctx2 = new InitialDirContext(env);
 } catch (NamingException e) {
 e.printStackTrace();
 try {
 //Works on port 636 (after 2nd attempt fails) and port 389
 ctx3 = new InitialDirContext(env);
 } catch (NamingException e) {
 e.printStackTrace();
 try {
 //Fails on port 636, works on port 389
 ctx4 = new InitialDirContext(env);
 } catch (NamingException e) {
 e.printStackTrace();
 Attributes attrs = ctx.getAttributes("[A USER DN]");
 System.out.println("Total attributes returned: " + attrs.size());
 try {
 ctx.close();
 ctx2.close();
 ctx3.close();
 ctx4.close();
 } catch (NamingException e) {
 e.printStackTrace();
 } catch (Exception ex) {
 ex.printStackTrace();
 System.exit(0);
}The java debug statements at the second exception:
Thread-1, WRITE: TLSv1 Handshake, length = 121
Thread-1, received EOFException: ignored
Thread-1, called closeInternal(false)
Thread-1, SEND TLSv1 ALERT: warning, description = close_notify
Plaintext before ENCRYPTION: len = 18
0000: 01 00 0F 78 84 EE 16 24 F6 99 B0 83 52 14 FF 86 ...x...$....R...
0010: 29 3C )<
Thread-1, WRITE: TLSv1 Alert, length = 18
Thread-1, called close()
Thread-1, called closeInternal(true)Again, any assistance is appreciated.

Multiple contexts are desired to establish a connection pool.The JNDI LDAP provider already does connection pooling so you don't need multiple initial contexts at all.

Sockets Closing In Rmi

I'v asked the question before but I was not fully ansered.
So sorry for the cross post.
I'm a newbie in Rmi I generaly use Object streams
To write C/S programs .
I'd like to know the understand the sockets mechnism underneath Rmi .
Client Side In plain socket C/S
once I establish a socket connection I use it for all subseqent calls to the server and close it.
Client Side Rmi
serverObject = Naming.lookup(serverObjectName);//opens a socket to server.[]
serverObjcet.helloMethod();[i]// the socket is used
serverObjcet.byeMethod();// the same socket is use
1. Closing Socket :I have not seen any close method used explicitly to close to close the connection to the server .when are the clent socket is closed.
2 are sockets s are opened and closed per remote
method call .
3.a good link about the topic how the sockets are handles in rmi.
fiontan, your help is needed
Thanks!
Joseph.

RMI creates listening sockets, one for each listened-to port. RMI
also creates connection sockets for outgoing connections and
connection sockets for incoming connections.
The number of listening sockets is usually one, because RMI exports
all objects on the "default" port unless told to use a different port
(for example, the Registry specifically requests port 1099).
The number of outgoing connections depends solely on the number of
concurrent outgoing calls. The simple rule is: if a thread wants to
make a remote call, and all the connections to the endpoint are in
use, then RMI opens a new connection to carry the call. If a
connection is free (meaning: there's no call in progress using that
connection), then RMI will reuse it for the next remote call.
RMI spawns one thread to listen to each listening socket (again,
usually one). When RMI accepts a new connection, it creates a new
thread: one thread handles the new connection, and the other goes back
to accept a new connection. When the connection closes, its
associated thread exits.
The connection-handling threads spawned by RMI are not serialized in
any way. If the calls arrive at the same time, they'll be run in
concurrent threads. The calls are still allowed to synchronize on
Java objects (such as JDBC Connection objects), but RMI does not do
such synchronization automatically.
One thing that commonly confuses people is that if a remote stub is
returned by a remote call, the client can sometimes be seen to make
two connections to the server. That happened because the distributed
garbage-collection subsystem needed to make a DGC.dirty() call to
notify the server that a new entity held a reference to the remote
object. Since the existing connection was busy, a new one was made.
Since then, we've found a way to do it with one connection (was that
in 1.1.6? can't remember).
Someone mentioned sockets. Sockets are not the same as
connections. There are two types of socket (for the purposes of this
discussion): connection sockets and listening sockets. A connection
socket is found on each end of an open TCP connection. A listening
socket is not associated with any TCP connection, but only exists as
an abstraction to allow the TCP kernel to decide which incoming
connections get accepted, and who gets the newly-accepted connection
socket (for those of you reading RFC-793, it's a wildcard-TCB which
executes passive-opens).
At any time, RMI has a small number of listening sockets (again,
usually one), and one connection socket for each open connection
(incoming or outgoing, it doesn't matter once the connection is
open). Note that the other end of a connection also has a socket; if
both ends of the connection are on the same machine, that machine's
TCB list will include both sockets.
If you run netstat, you'll notice the listening sockets are marked (in
state LISTEN) with "*" in place of the hostname, and "*.*" for the
remote endpoint. You'll also see a line for every connection socket
(TCB) in the ESTABLISHED state, giving the TCP addresses of each end
of the connection (this end and that end, respectively). If the
connection is to the local machine, you'll see the other socket as
well, with the TCP addresses the other way around. Here's an example:
% netstat -f inet -a | grep 1099
*.1099 *.* 0 0 0 0 LISTEN
replica.43559 replica.1099 32768 0 8192 0 ESTABLISHED
replica.1099 replica.43559 8192 0 32768 0 ESTABLISHED
I took this snapshot while running Registry.list() on my machine's
rmiregistry. The first line is the listening socket inside
rmiregistry. The second line is regtool's socket for the connection
to the registry. Notice that the kernel automatically assigned the
port number 43559 to the socket. The third line is rmiregistry's
socket for the same connection. (The four columns of numbers are
details of TCP's flow-control mechanism.)
I have one report that if you run netstat on Windows NT, it will show
lots of phantom LISTEN TCBs for connection sockets (for instance, it
would have shown a "*.43559 ... LISTEN" line in the example above). I
have no idea why it does this.

Socket Closing in java

I have a Java program to communicate with the server and when i click the close button in my program i get disconnected from the server .
But i have to do the same thing when i click the close button in the server......
I dont have the server code. how do i do that in my client code.....
With regards,
Freedom

this �s the piece of code for closing the socket in my program
public void CloseConnection()throws SocketException,IOException
          try
     //flush and close both "Instream" and "Outstream"
     bos.close();
     bis.close();
     instream.close();
     outstream.close();
     catch (IOException ex)
          ex.printStackTrace();
          tcpipSocket.close();
}

Basic stream/file/socket closing question

If you create a stream, it's generally considered good practice to call close() on that stream once you're done with it. the same for files and sockets. My question is what happens if I don't keep a reference to the object that needs closing. For example:
BufferedInputStream bis = new BufferedInputStream(new FileInputStream(new File("myfile.txt")));Clearly, I can close() bis. But does doing so close the FileInputStream, and the File? OR, will those remain open until the garbage collecter gets around to closing them. If not, is it considered good practice to keep references around for the sole purpose of explicitly closing the resource so you don't have to wait for garbage collection?
Finally, is it necessary to close() sockets/files/streams prior to calling System.exit()? It would save me a great deal of code in my exception handlers if I could simply exit() without explicitly freeing the resources I've opened prior to hitting the exception.
Thanks.

You should only need to call close on bis. That method call should take care of calling close on the underlying stream.

JDBC Adaper "socket closed"

Similar Messages

Maybe you are looking for