-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/2013 17:34, Christopher Schultz wrote: > On 10/3/13 11:42 AM, Mark Thomas wrote:
>> On the other hand, a JVM crash is a very strong motivation to fix >> an issue. > > For *you*, or for the user? For me. I haven't looked at the historical bugs. The APR code has changed so much for WebSocket I'd be inclined to close all the historical issues as WORKSFORME (assuming they didn't come with a reproducible test case) and focus on the current code. > Certainly it is for the user, but given the number of unfixed crash > reports in Bugzilla, it doesn't seem like tcnative-crash=quick-fix > from the team. I've been trying to investigate them whenever > possible but it's hard for me to get more information and, frankly, > I don't know anything about APR socket management itself so my time > is only of limited use. The AprEndpoint can be hard to get your head around starting from scratch. It has taken me a long time to feel comfortable making changes to that code. More comments in the AprEndpoint code should help. I've been trying to add them as I make changes. >> - documenting some of the constraints around using SSL would >> have saved me some time when getting SSL and WebSocket working > > Can you be more specific without just writing the documentation > yourself? I'm hoping to help, but I'm not sure what SSL constraints > you are alluding to. If you get a partial read/write you have to repeat the call with exactly the same parameters (i.e. the same objects) as you made the first call. >> -730053 > > This one isn't valid, as far as I can tell (the error string is > "Unrecognized resolver error"). 70053 is "Error string not > specified yet" so I'm not sure what that one is. 720000 is the offset for OS native error codes. 10053 is client abort on Windows. >> I can look them up to figure what they mean but it would save >> some time if the error report included a text version. > > tcnative doesn't have an error log, so where could those strings > go? Or were you thinking of having a bridge from Java code into > apr_strerr? I was thinking maybe an APR function that gave a textual error message for a given error code. Currently, the APR Java code reports just the error number. It would be nice to include a meaningful text message. > What about a program like perror that understands APR error codes? > I've written a simple one that could be helpful, but you probably > did that yourself already. Nope. I use Google :) > Anywhere more information can be added, I'm happy to help. > >>>> - Refactoring the connectors so all socket access goes >>>> through the SocketWrapper so there is a much smaller set of >>>> code to validate. >>> >>> I'm guessing you are tackling this task slowly over time. >> >> I am moving slowly in this direction. My ultimate aim is to have >> the connector type specific code only in the Endpoint and the >> SocketWrapper. No idea if that is possible. It is a longer term >> goal for Tomcat 9+ at this point. >> >> At the very least whenever I add functionality to the connectors >> (e.g. non-blocking IO) I do enough refactoring that I only have >> to add the new stuff once. > > Sounds good. Having unified code with only certain aspects > separated into BIO, NIO, and APR will certainly help folks like me > understand the "true" conceptual relationship between all of these > components and make it easier to actually help work on that part of > the code. Exactly. Simpler maintenance is one of my goals when reducing the duplication in the connector code. It is also something that can often be done in small and/or simple steps. There is always scope for someone to start contributing in that area (with the caveat that they need to be careful not to bite off more than they can chew - it is also easy to get into a right mess). Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTcrlAAoJEBDAHFovYFnnlfcP/A0O/1uiL0wBZ4ZrNZo9OQkR 134nCL7lt8RmpojWEH5vbySn8+94Qm1ycgwKXxX5a0RccSIPsqg2YZaH9BXLXqA8 hWaT4Yr38owGeY4ODXnVjsP4NGClDUOWjaxsBzg7AU5k7krwnNnGiaoBzPfT1CS1 juBr2OjcqiyJ2nC7eMO5Nfjmkv9Ru5B6Ksd28hMoRqBxuORXIUal2DEjxSdC1f6D iHkvn3a/zAdWGu+qpL2yR7Kqb3LT6yYDDCGiwZM3tsDqg+lRwu2yXmRbvo7zBEfL 8lG+WUHuvkC8+gqJeWDFg7ECUWSh6ZuX2AN0zudJtrvpFqcac+CHBR2ksapq0QUB s3qq82OZ0qF5ibJNCO9w1JO2XHxY3HGo6wUKZ4J9d0A1NMuiU7/Dnyn6ob0npOBV qOwRv0qrS0gaxOoLWWOvThgJnFMHBnhEra9CC9fkWF8huZo4zlupDVa6Zxr1FgyQ zwm8PFKHUPIh/MMzKGtn5jp9M1JW/0XGUbPHEe2sasTKmmlp3WizlVoborajRSfG P4vqPAYAZRl+r7kkr3ffMzQ/5sUkouPeD11qO4hRxUgntf2PeGSyONTsQRRNGEjV oT7uHinDWi+0HmEEASTvzMhJ84A7m5p9vmkGC323oPL/fgitUSSTWPRryuHmEt+a QMBvTmVxM8uaCzE6qfCW =D89L -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
