Am wondering why the socket is being closed before the client can send its close message to the broker; I wonder if the broker's InactivityMonitor is thinking that the client has been inactive for too long and discarding the connection?
James On 4/7/06, Gerdes, Mike <[EMAIL PROTECTED]> wrote: > > 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: [email protected] > 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: [email protected] > > 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. > -- James ------- http://radio.weblogs.com/0112098/
