migzai/irc-api

A Java IRC API

IRC-API is an IRC (Internet Relay Chat) API client library written in Java. The API offers a synchronous as well as an asynchronous programming model to the user, and has the ability to track the IRC connection state per session.

The API has been tested on various IRC networks, including EFnet, DALnet, Undernet, and offers a useful and detailed client interface to the server it connects to.

This is an open source project, and feedback is welcome from end-users as well as from developers.

Make sure you use the latest build!

Main features

• State retention
• Callbacks support / Asynchronous programming model
• Message Listeners, Message Filters
• Proxy support
• SSL support
• DCC support
• IPV6 support
• Java NIO
• SLF4J/Maven integration

Documentation

• Getting started
• Introduction
• A simple IRC client
• Message Listeners

irc-api's Issues

SEVERE error when (gracefully) disconnecting

What steps will reproduce the problem?
1. Connect to an IRC server
2. <do something, maybe connect to a channel>
3. ircapi.disconnect()
4. Now sometimes, though quite often, the exception below is logged. Not that 
it isn't fully thrown up. It is caught and logged.

What is the expected output? What do you see instead?
I expect no error at all, since I issue the disconnect command myself.

Instead, I (sometimes? but often) see:

21:51:34.982 SEVERE: [84] com.ircclouds.irc.api.AbstractApiDaemon.run() 
ApiDaemon
com.ircclouds.irc.api.comms.IConnection$EndOfStreamException
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.read(SSLSocketChannelConnection.java:55)
    at com.ircclouds.irc.api.AbstractMessageReader.available(AbstractMessageReader.java:46)
    at com.ircclouds.irc.api.AbstractApiDaemon.run(AbstractApiDaemon.java:30)


What version of the product are you using? On what operating system? Latest 
snapshot.

Nothing much to say, I guess ... If there are additional questions, please let 
me know.

Original issue reported on code.google.com by [email protected] on 17 Aug 2014 at 8:07

Bug? removing listener from PUBLIC listeners map twice

What steps will reproduce the problem?
- N.A. Discovered by reading the code. Either it is a mistake, or I didn't 
understand the code.

What is the expected output? What do you see instead?
- Expected: listener removed from PRIVATE and PUBLIC listeners collections.
- Actual: listener is removed twice from PUBLIC listeners collections. This 
only makes sense if it is added twice, but that isn't the case, and listeners 
added to PRIVATE listeners collection cannot be removed.

What version of the product are you using? On what operating system?
- Latest snapshot.

I found this one by reading through the code. I'm pretty sure it's just a 
copy-paste mistake. See attached patch for exact location and suggested change.

Original issue reported on code.google.com by [email protected] on 26 Nov 2014 at 9:45

Attachments:

• remove-public-visibility-list-twice.patch

NotYetConnectedException

When giving an invalid server name in the ircApi.connect() method the connection fails and the application tries to close the connection in the AbstractIRCSession class but this causes the application to throw an exception because there is no valid connection established.

Caused by: java.nio.channels.NotYetConnectedException
        at java.base/sun.nio.ch.SocketChannelImpl.ensureOpenAndConnected(SocketChannelImpl.java:178)
        at java.base/sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:452)
        at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.wrapAndWrite(SSLSocketChannelConnection.java:183)
        at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:115)
        at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:103)
        at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.close(SSLSocketChannelConnection.java:87)
        at com.ircclouds.irc.api.AbstractIRCSession.close(AbstractIRCSession.java:120)
        at com.ircclouds.irc.api.IRCApiImpl.closeSession(IRCApiImpl.java:463)
        at com.ircclouds.irc.api.IRCApiImpl.connect(IRCApiImpl.java:117)

My expectation is that this exception is propagated to the callback onFailure() method and no exception is thrown.

1.0-0015-SNAPSHOT

This version is referenced in an answer among the closed issues. However, that version is not accessible via Maven. Is this fixable?

Partial user id causes ArrayIndexOutOfBoundsException (Error in OM layer)

A user of the Jitsi IRC protocol support I'm working on encountered the runtime exception below. As I understand this was on a private IRC server. I haven't asked for the exact IRC server software, which is probably useful/relevant here.

I checked out the code and it looks like the code fails assuming that the <nick>!<user>@<host> is used, even though this format is not fully present in the server message. I have not seen the raw message though, so I can't say for sure.

This issue happens when the user is joining (or attempting to join) a channel. He will (at least some times) actually join, however it appears that since the flow is interrupted, Jitsi never actually gets a callback from irc-api. So I can't be any more specific than this.

I don't have an answer readily available on whether this is bad behaviour on the part of the server or whether this is a valid case not currently supported by irc-api.

 15:04:54.343 SEVERE: [289] com.ircclouds.irc.api.AbstractMessageReader.readMessage() Error from the OM layer
com.ircclouds.irc.api.om.IRCOMException: java.lang.ArrayIndexOutOfBoundsException: 1
    at com.ircclouds.irc.api.om.AbstractMessageFactory.build(AbstractMessageFactory.java:138)
    at com.ircclouds.irc.api.AbstractMessageReader.readMessage(AbstractMessageReader.java:64)
    at com.ircclouds.irc.api.AbstractApiDaemon.run(AbstractApiDaemon.java:32)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
    at com.ircclouds.irc.api.utils.ParseUtils.getUser(ParseUtils.java:32)
    at com.ircclouds.irc.api.om.AbstractPrivateMessageBuilder.build(AbstractPrivateMessageBuilder.java:20)
    at com.ircclouds.irc.api.om.AbstractMessageFactory.build(AbstractMessageFactory.java:90)
    ... 2 more

1.0-0015-SNAPSHOT is not on maven

I cant find version 1.0-0015-SNAPSHOT on maven:

https://mvnrepository.com/artifact/com.ircclouds.irc/irc-api

UnrealIRCd channel actions triggered as channel privmsg

What steps will reproduce the problem?
1. Sending an action to a channel

What is the expected output? What do you see instead?

Trigger onChannelAction() event rather than onChannelMessage() in 
VariousMessageListenerAdapter class.


What version of the product are you using? On what operating system?

1.0-0008 (with dependencies), Windows 7 x64, jdk1.6.0_45 in netbeans dev 
environment.


Please provide any additional information below.

Tested on UnrealIRCd 3.2.10.1 on windows with ssl

Original issue reported on code.google.com by [email protected] on 3 Jun 2013 at 5:18

"Connection reset by peer" not recognized as connection failure

What steps will reproduce the problem?
1. Configure server for SSL IRC connection.
2. Start connecting asynchronously.
3. Wait forever ... (not literally)

What is the expected output? What do you see instead?
* Expected: I get a async callback onFailure because the connection is (almost) 
immediately reset by the peer.
* Actual: I get a log message telling me that the connection has been reset, 
but no callback Success or Failure is ever issued. (The exception goes 
unnoticed.)

What version of the product are you using? On what operating system?
Latest snapshot, unmodified.

Stack trace:

[ApiDaemon] ERROR com.ircclouds.irc.api.AbstractMessageReader - Error reading 
from connection
java.io.IOException: Connection reset by peer
    at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
    at sun.nio.ch.IOUtil.read(IOUtil.java:197)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
    at com.ircclouds.irc.api.comms.SocketChannelConnection.read(SocketChannelConnection.java:38)
    at com.ircclouds.irc.api.AbstractMessageReader.available(AbstractMessageReader.java:48)
    at com.ircclouds.irc.api.AbstractApiDaemon.run(AbstractApiDaemon.java:27)

Original issue reported on code.google.com by [email protected] on 11 Apr 2014 at 8:26

Invalid call to close() upon connection timeout

Hi,

I've got this small issue when a connection is not successfully set up. In case 
a connection timeout occurs, some exception handling will call close() on a 
channel that wasn't successfully opened.


What steps will reproduce the problem?
1. Try to connect to server and fail with timeout (java.net.ConnectException)
2. Observe that an additional exception occurs while exception is traversing 
upwards.


What is the expected output? What do you see instead?
I expect only the actual ConnectException that started it all. Instead, I see 
an additional exception being produced.


What version of the product are you using? On what operating system?
Latest snapshot with slight modification to support custom SSL Context (issue 
10).

Please provide any additional information below.
Patch included.

Original issue reported on code.google.com by [email protected] on 7 Mar 2014 at 10:56

Attachments:

• close-if-open.diff

Nick change from IPv6 user builds incorrect nick change message

What steps will reproduce the problem?
1. Find channel with IPv6 user.
2. Wait until IPv6 user changes his nick.
3. Observe incorrect nick change message.

What is the expected output? What do you see instead?
Expected: 'zz_whitenite is now known as zz_zz_whitenite'

Observed: 'zz_whitenite is now known as 4f8:110:5248::2 NICK :zz_zz_whitenite'

What version of the product are you using? On what operating system?
1.0-0015-SNAPSHOT with some fixes (also submitted as issues)

FIX? (Same fix as suggested for issue 6.)
Start searching for colon past the user component. Patch with suggestion 
attached.

Original issue reported on code.google.com by [email protected] on 17 Jan 2014 at 11:24

Attachments:

• IPv6-issue-with-nick-changes.patch

Support for channel join failure caused by channel user limit

What steps will reproduce the problem?
1. Find a channel that is full (limit set and reached) (i.e. +l mode)
2. Attempt to join that channel

What is the expected output? What do you see instead?
Expected failure callback.

What version of the product are you using? On what operating system?
Nothing, because the response was not recognized as a failure.

Attached patch that adds the 471 Cannot join limit reply.
(See also ERR_CHANNELISFULL for 
http://tools.ietf.org/html/rfc1459.html#section-4.2.1.)

As always, please check the patch.

Original issue reported on code.google.com by [email protected] on 17 Jan 2014 at 10:37

Attachments:

• channel-cannot-join-limit.patch

Unable to connect to ZNC Bouncer

What steps will reproduce the problem?
1. Set up a ZNC bouncer (+ssl & non default port)
2. Connect API

What is the expected output? What do you see instead?
Expected: Either onSuccess or onFailure
Instead: the API never connects


What version of the product are you using? On what operating system?
API version 1.0-0011, Win 7 32bit, JavaSE 1.7
ZNC 0.206+deb2 on Debian Wheezy


Please provide any additional information below.
I also tried to connect to an older installation of ZNC and there seems to be 
an infinite loop when doAnyPendingHandshake() is called in read() in 
SSLSocketChannelConnection - hStatus always changes between states NEED_WRAP, 
NEED_UNWRAP and NEED_TASK.

Original issue reported on code.google.com by [email protected] on 9 Sep 2013 at 11:36

I use the sendChannelMessage and sendPrivateMessage function, but can not send success?

PRIVMSG from IPv6 address fails creating proper message

What steps will reproduce the problem?
1. Join channel with IPv6 user
2. Wait for message from this user.
3. Observe more than just his message (part of protocol data leaks)

Expected:
guess meta packages are confused. manually picked 3.12 and installed the 
headers first, then the linux-image package
works now

Observed:
79d:3e85:eca0:221:85ff:fe11:3e43 PRIVMSG #debian :guess meta packages are 
confused. manually picked 3.12 and installed the headers first, then the 
linux-image package
79d:3e85:eca0:221:85ff:fe11:3e43 PRIVMSG #debian :works now

What version of the product are you using? On what operating system?
1.0-0015-SNAPSHOT with one modification for supporting 
channel-join-failed-because-of-limit case. (will post another issue with patch 
for this)

FIX?
Source of the problem seems to be the colon being present in an IPv6 address. 
Suggestion for a fix provided below.

AbstractPrivateMessageBuilder : line 23
// Skip past the (possibly IPv6) user component when searching for ':'.
String _m = aMessage.substring(aMessage.indexOf(':', _components[0].length()) + 
1);

Original issue reported on code.google.com by [email protected] on 17 Jan 2014 at 10:25

Listener for Unknown Event or add UserCTCPMsg handling method to VariousMessageListenerAdapter

What steps will reproduce the problem?
1. Send a raw message using CTCP, passing a user-defined / custom command e.g. 
/ctcp <nick> CUSTOM_COMMAND
2. None of the handlers catch it, not even onUserPrivMessage(UserPrivMsg aMsg), 
or onError(ErrorMessage aMsg)
3.

What is the expected output? What do you see instead?
Other IRC libraries provide such a handler in their listener / adapter 
mechanisms. This allows users to leverage the CTCP protocol for their own needs.

What version of the product are you using? On what operating system?
The latest that could be found, 1.0-0014, on Windows 7 64-bit.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 3 Jan 2015 at 11:14

NPE when joining a (new?) channel

What steps will reproduce the problem?
1. Connect to an IRC server (irc.freenode.net)
2. Join a channel that hasn't existed up to now (#test9 or whatever)
   I am not sure, but I believe that it is caused by this. There might also be some other cause.
3. Join works fine, however a stack trace shows.

[ApiDaemon] ERROR com.ircclouds.irc.api.MessageDispatcherImpl - 
java.lang.NullPointerException
    at com.ircclouds.irc.api.utils.StateUtils.cloneChannel(StateUtils.java:14)
    at com.ircclouds.irc.api.state.AbstractIRCStateUpdater.savedOldState(AbstractIRCStateUpdater.java:184)
    at com.ircclouds.irc.api.state.AbstractIRCStateUpdater.onChannelMode(AbstractIRCStateUpdater.java:94)
    at com.ircclouds.irc.api.MessageDispatcherImpl.dispatchVarious(MessageDispatcherImpl.java:151)
    at com.ircclouds.irc.api.MessageDispatcherImpl.dispatchTo(MessageDispatcherImpl.java:62)
    at com.ircclouds.irc.api.MessageDispatcherImpl.dispatchToPrivateListeners(MessageDispatcherImpl.java:39)
    at com.ircclouds.irc.api.AbstractApiDaemon.run(AbstractApiDaemon.java:32)


What is the expected output? What do you see instead?
No stack trace.

What version of the product are you using? On what operating system?
1.0-0013

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 17 Nov 2013 at 5:08

running irc-api in server mode

Hi,
I am trying to use irc-api in one of my projects and my requirement is to run irc-api in both server and client mode.
After browsing code, not able to find how to user server mode.
This may be wrong forum to ask this query but could find other :(

Multiple irc-api instances may cause channel PRIVMSG messages to be fired as if User PRIVMSG

This one is actually pretty interesting/weird ... one irc-api instance 
influencing another ...

This is easiest to reproduce if you can halt the second irc-api instance during 
the connection process. Incidentally, you can do this if you provide a custom 
SSL context and use that to delay the connection process.

What steps will reproduce the problem?

1. Connect one irc-api instance to an IRC server. Make sure you are joined to a 
couple of channels, since we need IRC message to arrive while the second 
irc-api instance is connecting.

2. Connect a second irc-api instance to an IRC server (may be any server). Use 
a custom SSLContext instance to delay the connection process or do that in some 
other manner.

3. Delay the connection process at a point in the process before the connection 
with the IRC server is established and the message containing the accepted 
channel types are processed. (Or abort the process before the connection is 
established to make this state "permanent".)

4. At this point, PRIVMSG messages passing through the first irc-api instance 
(which is fully connected and operation) are *always* recognized as User 
private messages.

4a. It seems that this is caused by the DisconnectedIRCState instance that is 
set initially, while we are not yet connected. The IRCServerOptions instance 
that is set, configures a empty set of channel types. While constructing the 
PRIVATE_MESSAGE_BUILDER instance it collects the channel types (empty set) and 
the constructed message builder is assigned to a *static* variable. As a 
consequence, *all* irc-api instances evaluate PRIVMSG message using an empty 
set of channel types.

What is the expected output? What do you see instead?
- We expected messages to be identified as Channel private messages if they are.
- Messages are only ever recognized as User private messages, since the list of 
channel types is empty.

What version of the product are you using? On what operating system?
- Latest snapshot.

Patch attached.

Original issue reported on code.google.com by [email protected] on 26 Nov 2014 at 10:10

Attachments:

• accidental-USERPRIVMSG-builder.patch

Callbacks for forwarded channels don't work

What steps will reproduce the problem?
1. Connect to freenode.
2. Join #linux
3. Get joined to ##linux
4. ... but never any async callback response

Expected: Callback for successful join, but with different channel name, since 
we have been forwarded to join another channel.

Actual: Joined different channel with name according to forward, however there 
is no callback.

What version of the product are you using? On what operating system?
Linux, latest snapshot of irc-api lib.

The problem seems to be caused by the library expecting a 'channel' instance to 
be available while processing server message 470, however it is not yet 
available (i.e. channel == null). Message 470 therefore never gets processed 
correctly and the automatic join of the forward channel does not have a 
callback yet.
Attached is a suggestion for a fix, that seems to do the trick for me. I'm not 
sure if there's more to this, though.

Original issue reported on code.google.com by [email protected] on 19 Jan 2014 at 8:31

Attachments:

• fix-channel-forwarding.patch

IRC Connect to Twitch.tv fails

What steps will reproduce the problem?
1. Create a twitch account
2. Get an oauth token to test with real quick http://www.twitchapps.com/tmi/
3. Try to use IRCApi to log in to irc.twitch.tv 6667 using nickname and 
oauth:<token> as password

You should get successful response but instead you get an error.

Using version 1.0-0014

I tested using raw sockets and it fails if you don't pass the password first.  
If you changed the toString in ConnectCmd to output PASS first then it would 
work.  Also, you are not required to use a real name, so perhaps some null 
checks for realName, ident, etc. would be useful so you could skip the USER 
command if not specified.

Original issue reported on code.google.com by [email protected] on 12 Feb 2015 at 8:18

Possibility to specify an encoding

Hi,

I was trying to use this IRC lib because it seems to be the only one which is accessible through maven central and also seemed to be well designed. Now I stumbled on a problem: The default SocketChannelConnection always uses the system's default encoding. As far as I have researched the framework offers no easy way of exchanging the connection implementation without completely reimplementing the IRCApi interface.

Use a licence so other people can use your code.

I would like to create an IRC bot based on your code. It would be nice if you could put in a nice (commercally usable) licence for people who want to use your code legally.

Make irc-api an OSGi bundle

Hi,

Would you mind adding support as an OSGi bundle to the maven configuration?
This enables us to add the irc-api library as-is to the jitsi library 
dependencies. That is, without having to repackage it with in order to add OSGi 
support and enabling it to be easily shared among plugins that require the code.

It should be quite easy to make a bundle out of the irc-api library, since it 
is not (necessarily) needed to use the OSGi Activator infrastructure. There are 
no services that need to be registered and there's nothing that needs to be 
loaded beforehand. (At least, I don't think so ...)

I have attached a diff with the suggested changes in order to let maven build 
an OSGi bundle. This is probably the minimal set of changes and you probably 
want to add some more metadata w.r.t. author, description etc. But, since these 
are not obligatory I did not add them yet.

I used the maven-bundle-plugin from the Apache Felix project. You can find 
information on it here: 
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

Thanks,
Danny

Original issue reported on code.google.com by [email protected] on 30 Jun 2014 at 7:01

Attachments:

• osgi-bundle-support.diff

PONGs not being sent always in response to PINGs

Sometimes, not always, PONG responses aren't caught.  I created a PONG listener 
to log when the server receives a PING message, and many times it doesn't 
capture the PING:

Logs:
:b0rk.DE.EU.ShadowWorld.Net NOTICE AUTH :*** Looking up your hostname...
:b0rk.DE.EU.ShadowWorld.Net NOTICE AUTH :*** Found your hostname, cached
:b0rk.DE.EU.ShadowWorld.Net NOTICE AUTH :*** Checking Ident
PING :1153929233
:b0rk.DE.EU.ShadowWorld.Net NOTICE AUTH :If you are having difficulty 
connecting, try typing /QUOTE PON
G 1153929233
ERROR :Closing Link: 0.0.0.0 (Ping timeout)
Failed to Connect

Original issue reported on code.google.com by [email protected] on 8 May 2014 at 3:40

NPE when user statuses missing

What steps will reproduce the problem?
1. Not sure how this started, but at least receive a mode message that changes 
a user's mode.
2. Have message that changes a user's mode that does not have any statuses yet.
3. NPE occurs, since we're using NULL

What is the expected output? What do you see instead?
Expecting no output, just successfully modified state.
Got NPE (see below)

What version of the product are you using? On what operating system?
Linux, amd64, latest snapshot with some minor local modifications. (Also 
submitted to other issues.)

Please provide any additional information below.

Stack trace:
[ApiDaemon] ERROR com.ircclouds.irc.api.MessageDispatcherImpl - 
java.lang.NullPointerException
    at com.ircclouds.irc.api.state.AbstractIRCStateUpdater.onChannelMode(AbstractIRCStateUpdater.java:126)
    at com.ircclouds.irc.api.MessageDispatcherImpl.dispatchVarious(MessageDispatcherImpl.java:151)
    at com.ircclouds.irc.api.MessageDispatcherImpl.dispatchTo(MessageDispatcherImpl.java:62)
    at com.ircclouds.irc.api.MessageDispatcherImpl.dispatchToPrivateListeners(MessageDispatcherImpl.java:39)
    at com.ircclouds.irc.api.AbstractApiDaemon.run(AbstractApiDaemon.java:32)

Original issue reported on code.google.com by [email protected] on 18 Mar 2014 at 10:41

Channel join failure in general not handled (+ specifically BANNED not handled correctly)

What steps will reproduce the problem?
1. Connect to IRC server
2. Join channel where you are banned (or alternatively anything that causes 
failed channel join)

What is the expected output? What do you see instead?
- Expected: onFailure callback with error message.
- Actual: Nothing
- Actual - BANNED channel specific: Specifically for CHANNEL_JOIN_BANNED: 
IRCServerNumerics.CHANNEL_CANNOT_JOIN_BANNED (or something like that) not 
included in top if-conditions so this reply will not be handled.

What version of the product are you using? On what operating system?
- Latest snapshot.

Patch included that fixes the issues. Please note that tryInvokeCallback 
(IRCApiImpl) is used for both connect(...) and join(...) so checking connection 
will never work for both connect() and join(). My first thought on this is that 
I would always like feedback in case of failure, so it might be better to 
simply remove the if-statement checking for (non-)connectedness.

Original issue reported on code.google.com by [email protected] on 20 Sep 2014 at 10:09

Attachments:

• join-failed-banned.diff

Ability to provide a custom SSLContext for SSL connections

Hi,

I would like to know if you are open to including the following patch (or a 
better version ofcourse) to the code base.

I have made these modifications so I am able to supply a custom SSLContext for 
initiating secure connections. The reason for this is that we have an 
SSLContext implementation that verifies the certificate and if anything is 
wrong, it will ask the user for advice using a small popup window.
In order for this to work, we have to provide a custom SSLContext to use upon 
connecting using the SSLSocketConnection.

I have included a patch. It adds a method 'getCustomContext' to the interface, 
from which the (optional) custom SSLContext instance can be queried. If no 
custom SSLContext is provided (i.e. null) then it will just create one for 
itself just as you do now. If it is available, then it will use the provided 
context for its secure connection.

Let me know what you think. I know this patch works for me, but as always, it 
is by far not the only way of implementing this.

Original issue reported on code.google.com by [email protected] on 24 Feb 2014 at 10:23

Attachments:

• irc-api-custom-SSLContext.diff

Unappropriate cut off of user nick in ChannelModeMessage

What steps will reproduce the problem?
- When receiving a ChannelModeMessage instance, this instance contains a source 
with a nick that is missing the first character.

What is the expected output? What do you see instead?
- Expected: ChanServ!ChanServ@services
- Received: hanServ!ChanServ@services

What version of the product are you using? On what operating system?
- Latest snapshot, built by myself using maven.

Fix provided as an attachment.

Original issue reported on code.google.com by [email protected] on 4 Jan 2014 at 7:03

Attachments:

• irc-api-fix-ChannelModeMessage-nick-cutoff.patch

Documentation for DCC

Hi,
i'd like to use this library to receive dcc file transfers from another user.
Could you maybe offer some documentation on how i'd react to the incoming dcc event and maybe check the progress of the file transfer?

Potential thread-safety issue when receiving channels user list?

Hey, I'd like your opinion on the following ...

Occasionally I get 'null' when looking up the username of a 
parting/quitting/kicked user in a list I keep. This list is fed by the users 
list upon joining a channel and mutated upon receiving messages of 
joins/parts/quits/kicks. I think that this should not be possible since I 
should be able to just act on every mutation and keep a list that is current at 
every moment... (or am I wrong ???)

I was wondering, could it be that the many subsequent RPL_NAMREPLY messages 
could cause a thread-safety issue in the users-map which results in the 
occasionally dropped user? (I believe that LinkedHashMap is not synchronized by 
default.)

This would no problem for any variable except the user list since the user list 
is written to more than once.

I have attached a patch. It shows what I propose to fix. It is a bit hard to 
know for sure that this fixes my issue, so I am curious to know what you think.

Thanks :)

Original issue reported on code.google.com by [email protected] on 22 Nov 2013 at 11:09

Attachments:

• synchronize-users-map.patch

BufferOverflowException when issuing join-commands too quickly

What steps will reproduce the problem?
1. irc-api as used in Jitsi IRC protocol support.
2. Jitsi supports automatically joining specified channels, so some channels 
are configured to be auto-joined.
3. Connect to an IRC server, in my case I connect using a secure connection.
4. As soon as the connection is established according to irc-api, I flag the 
connection as being set.
5. Then, as a consequence, Jitsi starts issuing join-commands for every 
auto-joining channel.
6. Exception below gets thrown for some of the auto-joining channels, other 
auto-joins succeed without a hitch.

What is the expected output? What do you see instead?
- Expected: all messages get sent, i.e. without an exception.
- Actually: an exception occurs telling that a buffer overflow has occurred.

What version of the product are you using? On what operating system?
- Latest snapshot (rev. 194), no modifications.

At first glance, it looks like I have been able to fix this by simply 
increasing the appSendBuffer. I'm not sure if it is also necessary to increase 
the cipherSendBuffer, though it looks as it is necessary too.

19:13:56.744 SEVERE: [143] util.UtilActivator.uncaughtException().108 An 
uncaught exception occurred in thread=Thread[Thread-100,6,main] and message 
was: null
java.nio.BufferOverflowException
    at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:183)
    at java.nio.ByteBuffer.put(ByteBuffer.java:832)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:70)
    at com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
    at com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
    at com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
    at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:638)
    at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:580)
    at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
    at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
    at net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)

Original issue reported on code.google.com by [email protected] on 24 Aug 2014 at 5:45