[sip-comm-dev] someone wants to give a hand on the ICQ service?


#1

Hello all,

Some of you might have noticed that the CC mails on the cruisecontrol mailing list, have for some time now been announcing failures in unit testing. This is all because of me and I'd be happy to get some help cleaning out the problem!

It is very easily reproducible. Just run the cc-buildloop target a couple of times and it is bound to appear on at least 2 out of 3 runs.

Any help is much appreciated.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

A few more words on this one.

The problem would most often occur when running the testChangingStateToOnline() method located here:

net.java.sip.communicator.slick.protocol.icq.TestOperationSetPresence.testChangingStateToOnline(TestOperationSetPresence.java:215)

When appearing the test failure would be due to the lack of an event notifying that we have changed states to ONLINE and most often the test is being run after another test that leaves us in a Free For Chat state.

So in other words: Changing state from FreeForChat --to--> Online fails to generate an event.

I've also forgotten to mention that in order to be able to run the ICQ slick, you'd have to create an accounts.properties file in the lib directory. You can use the accounts.properties.template as a basis
and fill it in with ICQ uin information of accounts that you can create here:

https://icq.com/register

DON'T USE YOUR OWN ICQ ACCOUNT because the tests remove all contacts currently in your contact list.

The html reports of the tests are available in the test-reports/html/ directory and are viewable with any browser.

Let me know if you need any further information.

Cheers
Emil

Emil Ivov wrote:

···

Hello all,

Some of you might have noticed that the CC mails on the cruisecontrol mailing list, have for some time now been announcing failures in unit testing. This is all because of me and I'd be happy to get some help cleaning out the problem!

It is very easily reproducible. Just run the cc-buildloop target a couple of times and it is bound to appear on at least 2 out of 3 runs.

Any help is much appreciated.

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

I had hoped to find some time to look at your problem later this week, but it looks as if
you have solved it already. Is that so?
Regards,

Brian

···

On Wed, 15 Feb 2006 08:11:15 +0900, Emil Ivov wrote:

Some of you might have noticed that the CC mails on the cruisecontrol
mailing list, have for some time now been announcing failures in unit
testing. This is all because of me and I'd be happy to get some help
cleaning out the problem!
It is very easily reproducible. Just run the cc-buildloop target a
couple of times and it is bound to appear on at least 2 out of 3 runs.
Any help is much appreciated.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Brian,

I was about to send a mail on that. Glad you asked though, I was afraid no one had heard my cry for help :).

I had hoped to find some time to look at your problem later this week, but it looks as if you have solved it already. Is that so?

Solved? Not really. Temporarily patched would be more suitable of a description for what I did.

As I explained earlier the problem occurred when testing changes in presence states. A series of tests in the TestOperationSetPresence class would make the stack enter new presence states and verify that the transition had generated all the corresponding events. The test that failed was the one that brought the stack back to the on-line state as that particular transition did not generate any events.

I had previously alredy added a Thread.sleep() at the end of each state transition test as I had the feeling that the AIM server was not liking rapid consecutive transitions. All I did now was increase that delay from 2000 to 5000 ms, and that seemed to somehow work.

As you can see this is far from being a solution but at least it stops the "Build Failed" mails. In other words you are welcome to still have a look at this and find a real solution.

OTOH, in case you'd like to tackle sth else, we also have a problem with ICQ nicknames. The joustsim stack that we use was primarily created for AIM and it doesn't implement the ICQ requests that deal with nicknames. I've been talking to Keith Lea (the author) about that and he had sent me some classes that someone else had written and that supposedly implement this stuff. I haven't yet had the time to look into those since I am working on the MetaContactList now so if you (or anyone else for that matter) are interested in this, I'd be glad to send them over.

Let me know if that's the case.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Brian,

I was about to send a mail on that. Glad you asked though, I was afraid
no one had heard my cry for help :).

I had hoped to find some time to look at your problem later this week, but it looks as if
you have solved it already. Is that so?

Solved? Not really. Temporarily patched would be more suitable of a
description for what I did.

As I explained earlier the problem occurred when testing changes in
presence states. A series of tests in the TestOperationSetPresence class
would make the stack enter new presence states and verify that the
transition had generated all the corresponding events. The test that
failed was the one that brought the stack back to the on-line state as
that particular transition did not generate any events.

I had previously alredy added a Thread.sleep() at the end of each state
transition test as I had the feeling that the AIM server was not liking
rapid consecutive transitions. All I did now was increase that delay
from 2000 to 5000 ms, and that seemed to somehow work.

Oh dear! I've been there before many times, but (I think) always with ant running
jUnit tests which cause several Threads to run... this shouldn't matter, but often it
does. There's some old documentation on how (in theory) to extend jUnit for
multi-threading classes, and I even got desperate enough to plan the work once.
IBM wrote a new test harness for multi-threading last year (alphaworks software),
but I didn't like it for many reasons.

Am I right in thinking these failing tests involve multiple Threads - I know I could
look with a debugger, but I've got too many computers doing stuff at the moment.

As you can see this is far from being a solution but at least it stops
the "Build Failed" mails. In other words you are welcome to still have a
look at this and find a real solution.

Can you tell me the name of the test class and an individual test that is failing? I
presume I only need to comment-out a sleep and it will break?

I think this problem will take a while to resolve properly, but I will take a quick look
to see if it matches my own experiences. If it does match, then you can "look forward"
to randomly failing tests and hours of frustration tinkering with sleep times when ever
something apparently-unrelated has changed.

OTOH, in case you'd like to tackle sth else, we also have a problem with
ICQ nicknames. The joustsim stack that we use was primarily created for
AIM and it doesn't implement the ICQ requests that deal with nicknames.
I've been talking to Keith Lea (the author) about that and he had sent
me some classes that someone else had written and that supposedly
implement this stuff. I haven't yet had the time to look into those
since I am working on the MetaContactList now so if you (or anyone else
for that matter) are interested in this, I'd be glad to send them over.

Let me know if that's the case.

Nice try! I'm afraid I've got a backlog of (paid) work at the moment, with some
aggressive-but-justified deadlines. I'll be working 7 days a week for some time,
so can only spare SipComm the occasional hour or so.
Regards,

Brian

···

On Tue, 21 Feb 2006 11:29:38 +0100, Emil Ivov wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Am I right in thinking these failing tests involve multiple Threads - I know I could
look with a debugger, but I've got too many computers doing stuff at the moment.

All testing inside the icq SLICK is run in a single threaded manner so the problem is not in multithreaded testing. Whether it may relate to some race condition inside the stack, that I can't be certain.

Can you tell me the name of the test class and an individual test that is failing? I
presume I only need to comment-out a sleep and it will break?

Here's the corresponding part of the exception that caused the failure:
  at net.java.sip.communicator.slick.protocol.icq.TestOperationSetPresence.subtestStateTransition(TestOperationSetPresence.java:256)

  at net.java.sip.communicator.slick.protocol.icq.TestOperationSetPresence.testChangingStateToOnline(TestOperationSetPresence.java:215)

(keep in mind that line numbers might have changed)

The sleep you're looking for is located in the same class in a method called:

pauseBetweenStateChanges().

Good luck.

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net