I have made a few testings and it seems to be some kind of a timing problem or so. I have enabled full ssl debugging and compared both output files with diff. There are some different ports and some lines are in a different order...nothing special here so I ignored that. Then there is a point in the case when no error occurs, where a thread sends data. This is not the case when the error occurs. Ok this error happens on two different machines with different configurations. So from this I would say, that the error occurs, when the socket is closed before one thread can send its message. As this seams to be a timing problem, it would explain, why the error doesn't happen in all cases.
-----Ursprüngliche Nachricht----- Von: James Strachan [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 6. April 2006 14:00 An: activemq-users@geronimo.apache.org Betreff: Re: a strange ssl error Thanks for the heads up Mike. Its a bit surprising the close-thing; as really all that happens with a close is we asynchronously send a close command, then shut down the socket - but it appears from your stack trace that the write of the close command fails while flushing the buffer to the socket due to the socket already being closed which I don't quite understand. Bizarre :) If you can think of anything else to help us nail down this strangeness please do let us know. BTW I wonder if its anything to do with tcpNoDelayEnabled setting? (i.e. whether we send complete packets or wait for them to fill up etc). http://activemq.org/Configuring+Wire+Formats On 4/6/06, Gerdes, Mike <[EMAIL PROTECTED]> wrote: > > thanks for the fast answer. Ok there is no part of my network that closes the > connection, but your hint looks close to the error. It doesn't happen with > tcp, but SSL throws sockettimeout messages all the time and calls a close > after the message is transfered. The timeouts don't cause the connection to > be closed while it is idle, so I guess there might be something in the code > that closes the connection or so. > The funny thing is that everything works fine as long as no close is called. > That means I can send and recieve messages without any problems all the time, > so the connection is not totally dropped. But when I want to close it then > the error occurs. > It is not that critical, as I can just leave all connections open, but it > might be a problem in an enviroment with many clients and when the > application that gets the exception crashes. > > anyway thanks again james > > -----Ursprüngliche Nachricht----- > Von: James Strachan [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 6. April 2006 12:57 > An: activemq-users@geronimo.apache.org > Betreff: Re: a strange ssl error > > > > On 4/6/06, Gerdes, Mike <[EMAIL PROTECTED]> wrote: > > > > hi, > > > > so in my experiments with ssl, which looked promising, I have encountered a > > new error. To be honest I have no clue what causes this error or why it is > > caused at all. > > First this error happens in compination of ssl and jms, second the error > > only happens in about 50% of all cases, third and the strangest thing is, > > that the error only happens when a connection.close(); is in class file and > > I haven't noticed it when the connection is not closed. Also it looks like > > the error is happening shortly before the connection.close(); command is > > executed. At least the error is displayed right in the output of a loop > > that runs before the connection.close();. > > > > I am totally confused by this error and and argh.... > > From the stack trace it looks like you are trying to close a client > connection but that fails because the socket has already been closed > by someone else - though I've no bright ideas why that might be the > case I'm afraid. Could it be a firewall or some other part of your > network is simply just dropping the underlying socket? Or are there > any broker side warnings/errors that is causing it to drop the socket? > Or was the client just inactive for too long? > > -- > > James > ------- > http://radio.weblogs.com/0112098/ > > > > This mail has originated outside your organization, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > This e-mail is intended only for the above addressee. It may contain > privileged information. If you are not the addressee you must not copy, > distribute, disclose or use any of the information in it. If you have > received it in error please delete it and immediately notify the sender. > Security Notice: all e-mail, sent to or from this address, may be > accessed by someone other than the recipient, for system management and > security reasons. This access is controlled under Regulation of > Investigatory Powers Act 2000, Lawful Business Practises. > -- James ------- http://radio.weblogs.com/0112098/ This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message.
