Using .shutdown() provides a stacktrace.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use http://paste.thezomg.com/7296/35951268/
2. Call shutdown() instead of disconnect()

What is the expected output? What do you see instead?
Should see a clean quit. http://pastebin.com/W96smmWu is an actual result.

Details:
I believe .shutdown() should be available to terminate the connection right 
away, without waiting for the server to respond to a QUIT. I've tried messing 
around a little bit, but the issue clearly is threading here, and that one of 
my weakspots in programming :)

As a side note, I've began writing a fresh core using some of the ideas from 
PircBotX (such as threaded inputs/outputs), and it doesn't appear to suffer 
from this issue, tho trying to move my codebase into PircBotX's hasn't worked. 
I can provide my code if wished, but it's not that different. The notable 
difference is I track isConnected within the main connection class, not the 
input-thread class, and use synchronized(object) stanza to keep it behaving.

Original issue reported on code.google.com by entityreborn on 30 Jan 2013 at 2:30

[GoogleCodeExporter]

I guess a semi-acceptable solution is to catch SocketExceptions, and if the 
socket is closed, ignore the exception.

Original comment by entityreborn on 30 Jan 2013 at 5:22

[GoogleCodeExporter]

Your not really supposed to call .shutdown() unless there's a specific reason 
you need to. Shutdown is handled automatically by InputThread and the JVM 
shutdown hook. 

And for the rewritten core, how much are you rewriting? The connect code? All 
the send* methods and friends? 

Original comment by Lord.Qua...@gmail.com on 31 Jan 2013 at 7:36

• Changed state: Invalid

[GoogleCodeExporter]

Pretty much everything. I have started from scratch, using some ideas (Such as 
pircbot's input/output threading, pircbotx's manytomanymap, etc) but not copy 
pasting anything. 

Right now all I have is the basic core, connection code, a few sparse events, 
some (as yet, incomplete) user and channel tracking, etc.

I've actually used a seperate event system as well, based on annotations, but 
that's besides the point.

I remember in a convo with you that you weren't willing to rewrite everything, 
so I thought I'd take a private crack at it.

If you are thinking of merging it or some of it's code with PircBotX, license 
issues need to be worked out first. I emailed the auther of PircBot the other 
day with no response so far, I might fire off a new one in the next week or 
three.

Original comment by entityreborn on 1 Feb 2013 at 5:21

[GoogleCodeExporter]

By the way, the bots timed out of the main channel yesterday and haven't 
returned.

Original comment by entityreborn on 1 Feb 2013 at 5:22

[GoogleCodeExporter]

My server network was down, but I forgot about the bots. 

With the rewritten core, that's a new major release but I'm wondering how this 
is going to affect a) The name of the project which implies a fork of PircBot, 
not an entirely different library and b) Existing users who will want to port 
their project (remember some might of recently completed a pircbot -> pircbotx 
upgrade, asking them to go to pircbotx2 is a little much). Mind moving the core 
rewrite to a new issue so we can keep things in one place?

Original comment by Lord.Qua...@gmail.com on 1 Feb 2013 at 6:32

[GoogleCodeExporter]

This isnt a fork at all, all code is hand written by me, using ideas
from pircbot and pircbotx. I also wasnt sure if i wanted to add the
code to pircbotx or not, heh.

On Jan 31, 2013, at 10:32 PM, "pircbotx@googlecode.com"
<pircbotx@googlecode.com> wrote:

Original comment by entityreborn on 1 Feb 2013 at 4:17