[jitsi-dev] USER_SEARCH_ENABLED & USER_SEARCH_SERVICE properties are broken.


#1

Hello devs,

Just an update about this issue.

The commit that introduced regression in the search service logic was
authored on Nov 20, 2014:

"Removes dependency on running ProtocolProviderServiceJabberImpl from
ScServiceDiscoveryManager"

https://github.com/jitsi/jitsi/commit/6cb3c0e2dea8015e31a281d21f47861e31105ab4

Could you please have a look? I used the git reset function to locate the
right commit in order to help you investigate the issue.
I'd have been more than happy to fix it myself if I knew how but
unfortunately, I don't. :slight_smile:

Best regards,
Marin

···

Hello devs,

Recently I noticed that my local Jitsi installation is not able to retrieve
contacts from the openfire search service.
The service seems to work fine with Spark & Pidgin.

I checked the logs and found that:

16:10:02.825 INFO: [150]
impl.gui.main.contactlist.TreeContactList.queryStatusChanged().477 Contact
query error occured:net.java.sip.communicator.plugin.usersearch.UserSearchQuery at 16d618a <http://lists.jitsi.org/mailman/listinfo/dev>
16:10:02.826 SEVERE: [150] util.UtilActivator.uncaughtException().108 An
uncaught exception occurred in thread=Thread[Thread-113,6,main] and message
was: org.jivesoftware.smackx.search.SimpleUserSearch cannot be cast to
net.java.sip.communicator.impl.protocol.jabber.extensions.usersearch.UserSearchIQ
java.lang.ClassCastException:
org.jivesoftware.smackx.search.SimpleUserSearch cannot be cast to
net.java.sip.communicator.impl.protocol.jabber.extensions.usersearch.UserSearchIQ
at
net.java.sip.communicator.impl.protocol.jabber.UserSearchManager.getSearchForm(UserSearchManager.java:122)
at
net.java.sip.communicator.impl.protocol.jabber.UserSearchManager.searchForString(UserSearchManager.java:136)
at
net.java.sip.communicator.impl.protocol.jabber.OperationSetUserSearchJabberImpl.search(OperationSetUserSearchJabberImpl.java:195)
at
net.java.sip.communicator.plugin.usersearch.UserSearchQuery.providerAdded(UserSearchQuery.java:104)
at
net.java.sip.communicator.plugin.usersearch.UserSearchQuery.run(UserSearchQuery.java:78)
at
net.java.sip.communicator.service.contactsource.AsyncContactQuery$1.run(AsyncContactQuery.java:314)

Is there any chance that the search functionallity got broken with the
latest release?

Best regards,
Marin


#2

Hi Marin,

···

On Tue, Apr 21, 2015 at 8:25 PM, Marin Dzhigarov <m.dzhigarov@gmail.com> wrote:

Hello devs,

Just an update about this issue.

The commit that introduced regression in the search service logic was
authored on Nov 20, 2014:

"Removes dependency on running ProtocolProviderServiceJabberImpl from
ScServiceDiscoveryManager"

https://github.com/jitsi/jitsi/commit/6cb3c0e2dea8015e31a281d21f47861e31105ab4

Could you please have a look? I used the git reset function to locate the
right commit in order to help you investigate the issue.
I'd have been more than happy to fix it myself if I knew how but
unfortunately, I don't. :slight_smile:

Thanks for looking into it ! I'll check that commit.

Regards,
Pawel


#3

Hi,

Hi Marin,

Hello devs,

Just an update about this issue.

The commit that introduced regression in the search service logic was
authored on Nov 20, 2014:

"Removes dependency on running ProtocolProviderServiceJabberImpl from
ScServiceDiscoveryManager"

https://github.com/jitsi/jitsi/commit/6cb3c0e2dea8015e31a281d21f47861e31105ab4

Are you sure it's this one ? I can't really find how it's related.
Also I've never worked with Openfire search service and it will take
me a lot of time to configure and try it. Could you please apply my
patch and see if more errors are visible ? This looks like an issue
with UserSearchProvider registration which is supposed to parse the
search IQ.

Regards,
Pawel

additional_logging.patch (1 KB)

···

On Wed, Apr 22, 2015 at 11:50 AM, Paweł Domas <pawel.domas@jitsi.org> wrote:

On Tue, Apr 21, 2015 at 8:25 PM, Marin Dzhigarov <m.dzhigarov@gmail.com> wrote:


#4

Hello Pawel,

Thanks for looking into it!

I applied your patch on the mentioned commit and in addition to the class
cast exception from my previous mail I now get this during startup:

08:34:12.767 SEVERE: [35]
impl.protocol.jabber.ProtocolProviderServiceJabberImpl.initialize().1621
java.lang.IllegalStateException: ProviderManager singleton already set
java.lang.IllegalStateException: ProviderManager singleton already set
    at
org.jivesoftware.smack.provider.ProviderManager.setInstance(ProviderManager.java:154)
    at
net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.initialize(ProtocolProviderServiceJabberImpl.java:1615)
    at
net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderFactoryJabberImpl.createService(ProtocolProviderFactoryJabberImpl.java:137)
    at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:983)
    at
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:204)
    at
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:446)
    at
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:562)
    at
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:26)
    at
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:487)

I'm absolutely positive that this exactly is the commit that breaks the
search service logic. I too couldn't find any relation between the two
though... Anyway, I hope the additional logs will clear things up.

Best regards,
Marin

···

On Wed, Apr 22, 2015 at 4:45 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hi,

On Wed, Apr 22, 2015 at 11:50 AM, Paweł Domas <pawel.domas@jitsi.org> > wrote:
> Hi Marin,
>
> On Tue, Apr 21, 2015 at 8:25 PM, Marin Dzhigarov <m.dzhigarov@gmail.com> > wrote:
>> Hello devs,
>>
>> Just an update about this issue.
>>
>> The commit that introduced regression in the search service logic was
>> authored on Nov 20, 2014:
>>
>> "Removes dependency on running ProtocolProviderServiceJabberImpl from
>> ScServiceDiscoveryManager"
>>
>>
https://github.com/jitsi/jitsi/commit/6cb3c0e2dea8015e31a281d21f47861e31105ab4

Are you sure it's this one ? I can't really find how it's related.
Also I've never worked with Openfire search service and it will take
me a lot of time to configure and try it. Could you please apply my
patch and see if more errors are visible ? This looks like an issue
with UserSearchProvider registration which is supposed to parse the
search IQ.

Regards,
Pawel


#5

Hello Marin,

···

On Thu, Apr 23, 2015 at 7:38 AM, Marin Dzhigarov <m.dzhigarov@gmail.com> wrote:

Hello Pawel,

Thanks for looking into it!

I applied your patch on the mentioned commit and in addition to the class
cast exception from my previous mail I now get this during startup:

08:34:12.767 SEVERE: [35]
impl.protocol.jabber.ProtocolProviderServiceJabberImpl.initialize().1621
java.lang.IllegalStateException: ProviderManager singleton already set
java.lang.IllegalStateException: ProviderManager singleton already set
    at
org.jivesoftware.smack.provider.ProviderManager.setInstance(ProviderManager.java:154)
    at
net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.initialize(ProtocolProviderServiceJabberImpl.java:1615)
    at
net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderFactoryJabberImpl.createService(ProtocolProviderFactoryJabberImpl.java:137)
    at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:983)
    at
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:204)
    at
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:446)
    at
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:562)
    at
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:26)
    at
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:487)

I'm absolutely positive that this exactly is the commit that breaks the
search service logic. I too couldn't find any relation between the two
though... Anyway, I hope the additional logs will clear things up.

Hmm this exception doesn't help - it was expected. Will have to try
something else...

Regards,
Pawel


#6

Hello Marin,

Like discussed off the list the issue should be fixed[1] now. Thanks for help !

[1]: https://github.com/jitsi/jitsi/commit/8f11719b14053c9161c9ada88509f9b8ccd9fa44

Regards,
Pawel

···

On Thu, Apr 23, 2015 at 8:41 AM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hello Marin,

On Thu, Apr 23, 2015 at 7:38 AM, Marin Dzhigarov <m.dzhigarov@gmail.com> wrote:

Hello Pawel,

Thanks for looking into it!

I applied your patch on the mentioned commit and in addition to the class
cast exception from my previous mail I now get this during startup:

08:34:12.767 SEVERE: [35]
impl.protocol.jabber.ProtocolProviderServiceJabberImpl.initialize().1621
java.lang.IllegalStateException: ProviderManager singleton already set
java.lang.IllegalStateException: ProviderManager singleton already set
    at
org.jivesoftware.smack.provider.ProviderManager.setInstance(ProviderManager.java:154)
    at
net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.initialize(ProtocolProviderServiceJabberImpl.java:1615)
    at
net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderFactoryJabberImpl.createService(ProtocolProviderFactoryJabberImpl.java:137)
    at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:983)
    at
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:204)
    at
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:446)
    at
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:562)
    at
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:26)
    at
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:487)

I'm absolutely positive that this exactly is the commit that breaks the
search service logic. I too couldn't find any relation between the two
though... Anyway, I hope the additional logs will clear things up.

Hmm this exception doesn't help - it was expected. Will have to try
something else...

Regards,
Pawel


#7

Hello,

Can anyone please trigger a build so that we can get the fix in the
nightlies? :slight_smile:

Best regards,
Marin

···

On Thu, Apr 23, 2015 at 11:07 AM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hello Marin,

Like discussed off the list the issue should be fixed[1] now. Thanks for
help !

[1]:
https://github.com/jitsi/jitsi/commit/8f11719b14053c9161c9ada88509f9b8ccd9fa44

Regards,
Pawel

On Thu, Apr 23, 2015 at 8:41 AM, Paweł Domas <pawel.domas@jitsi.org> > wrote:
> Hello Marin,
>
> On Thu, Apr 23, 2015 at 7:38 AM, Marin Dzhigarov <m.dzhigarov@gmail.com> > wrote:
>> Hello Pawel,
>>
>> Thanks for looking into it!
>>
>> I applied your patch on the mentioned commit and in addition to the
class
>> cast exception from my previous mail I now get this during startup:
>>
>> 08:34:12.767 SEVERE: [35]
>> impl.protocol.jabber.ProtocolProviderServiceJabberImpl.initialize().1621
>> java.lang.IllegalStateException: ProviderManager singleton already set
>> java.lang.IllegalStateException: ProviderManager singleton already set
>> at
>>
org.jivesoftware.smack.provider.ProviderManager.setInstance(ProviderManager.java:154)
>> at
>>
net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.initialize(ProtocolProviderServiceJabberImpl.java:1615)
>> at
>>
net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderFactoryJabberImpl.createService(ProtocolProviderFactoryJabberImpl.java:137)
>> at
>>
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:983)
>> at
>>
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:204)
>> at
>>
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:446)
>> at
>>
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:562)
>> at
>>
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:26)
>> at
>>
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:487)
>>
>> I'm absolutely positive that this exactly is the commit that breaks the
>> search service logic. I too couldn't find any relation between the two
>> though... Anyway, I hope the additional logs will clear things up.
>
> Hmm this exception doesn't help - it was expected. Will have to try
> something else...
>
> Regards,
> Pawel


#8

Hi Marin,

···

On Mon, Apr 27, 2015 at 7:36 AM, Marin Dzhigarov <m.dzhigarov@gmail.com> wrote:

Hello,

Can anyone please trigger a build so that we can get the fix in the
nightlies? :slight_smile:

Oh it looks like the build is broken. I'll have a look.

Regards,
Pawel