SSL Debug Exception

Brian Smith

unread,

Apr 18, 2004, 3:12:34 PM4/18/04

to

Has anyone encountered this exception before when ssl.debug=true? We are having
issues with open sockets and I suspect this may be related. The fundamental question
is whether or not the socket actually closes or if the exception keeps the socket
open.

TIA

Brian

====

<000000> <write APPLICATION_DATA offset = 0 length = 183>

####<Apr 18, 2004 1:30:22 PM EST> <Debug> <TLS> <inuxapp01> <myserver> <ExecuteThread:
'1' for queue: 'weblogic.socket.Muxer'> <<WLS
Kernel>> <> <000000> <NEW ALERT: com.certicom.tls.record.alert.Alert@b63dfe Severity:
1 Type: 0
java.lang.Throwable: Stack trace

at weblogic.security.utils.SSLSetup.debug(SSLSetup.java:265)

at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)

at com.certicom.tls.interfaceimpl.TLSConnectionImpl.closeWriteHandler(Unknown
Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.close(Unknown Source)

at javax.net.ssl.impl.SSLSocketImpl.close(Unknown Source)

at weblogic.socket.SocketMuxer.closeSocket(SocketMuxer.java:266)

at weblogic.socket.SocketMuxer.cleanupSocket(SocketMuxer.java:604)

at weblogic.socket.SocketMuxer.deliverExceptionAndCleanup(SocketMuxer.java:568)

at weblogic.socket.SocketMuxer.deliverHasException(SocketMuxer.java:520)

at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:703)

at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:627)

at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:123)

at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:32)

at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)

at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

Brian Smith

unread,

Apr 18, 2004, 4:30:00 PM4/18/04

to

Also...has anyone experienced the exception below before with ssl.debug=true?
Interestingly enough it occured about 13 hours after the last SSL client access.
In addition, it appeared to clean up the idle socket.

<000000> <SSLFilter.isActivated: false>

####<Apr 18, 2004 12:54:51 PM EST> <Debug> <TLS> <inuxdev01> <myserver> <ExecuteThread:
'13' for queue: 'default'> <<WLS Kernel>> <>
<000000> <NEW ALERT: com.certicom.tls.record.alert.Alert@1b766c1 Severity: 1

Type: 0
java.lang.Throwable: Stack trace

at weblogic.security.utils.SSLSetup.debug(SSLSetup.java:265)

at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)

at com.certicom.tls.interfaceimpl.TLSConnectionImpl.closeWriteHandler(Unknown
Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.close(Unknown Source)

at javax.net.ssl.impl.SSLSocketImpl.close(Unknown Source)

at weblogic.t3.srvr.ListenThread.rejectCatastrophe(ListenThread.java:439)

at weblogic.t3.srvr.SSLListenThread$1.execute(SSLListenThread.java:523)

Tony

unread,

Apr 18, 2004, 8:52:43 PM4/18/04

to

The debug exception message ALERT Sev 1 Type 0 is just the way the SSL debug
trace shows
an SSL/TLS CLOSE_NOTIFY alert message is being created/received. The
"exception" is
just generated by the debug code to show the calling stack, it just happens
to be done that way
for all SSL alert messages.

The second alert you posted looks like a connection was timed out, and as a
result the SSL
socket was being closed and a CLOSE_NOTIFY was being created to send to the
SSL peer.

Tony

"Brian Smith" <brps...@hotmail.com> wrote in message
news:4082e548$1...@newsgroups.bea.com...