[jitsi-dev] JVM hang when starting second Jitsi instance (on Windows)


#1

Hristo,

This is still there, and it is still extremely annoying. Could please,
please take a look at that?

Ingo

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of

Ingo

···

-----Original Message-----
Bauersachs
Sent: Dienstag, 8. April 2014 22:17
To: 'Jitsi Developers'
Subject: Re: [jitsi-dev] JVM hang when starting second Jitsi instance (on
Windows)
So, by trial and error: renaming/deleting jmsoutlookaddrbook.dll makes the
problem disappear.

-> Hristo, something went seriously wrong with your recent updates to
integrate the calendar. Could you please have a look at that?

Ingo

dev-bounces@jitsi.org wrote on auersachs: >> Windows) >> Hey >> >> I have a VERY strange behavior: as soon as I launch a second instance of

Jitsi, the one that was launched first completely hangs. I cannot even
create a thread dump (JVisualVM starts to hang too as soon as I try to
attach to the hanging Jitsi), nor is there a JVM crash log.

This has never been a problem and I'm wondering if anyone has seen
something similar?

Ingo


#2

So the thing is we don't know which change caused this exaclty (could
have been something from Hristo or Damencho ) so we need to
investigate.

Does it break anything other than the multiple instance case?

Hristo can you try checking this out at the end of next week?

···

On Tue, Apr 29, 2014 at 11:21 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Hristo,

This is still there, and it is still extremely annoying. Could please,
please take a look at that?

Ingo

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of

Ingo

Bauersachs
Sent: Dienstag, 8. April 2014 22:17
To: 'Jitsi Developers'
Subject: Re: [jitsi-dev] JVM hang when starting second Jitsi instance (on
Windows)
So, by trial and error: renaming/deleting jmsoutlookaddrbook.dll makes the
problem disappear.

-> Hristo, something went seriously wrong with your recent updates to
integrate the calendar. Could you please have a look at that?

Ingo

dev-bounces@jitsi.org wrote on auersachs: >>> Windows) >>> Hey >>> >>> I have a VERY strange behavior: as soon as I launch a second instance of

Jitsi, the one that was launched first completely hangs. I cannot even
create a thread dump (JVisualVM starts to hang too as soon as I try to
attach to the hanging Jitsi), nor is there a JVM crash log.

This has never been a problem and I'm wondering if anyone has seen
something similar?

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#3

I’ll check it.

···

On Apr 30, 2014, at 10:46 PM, Emil Ivov <emcho@jitsi.org> wrote:

So the thing is we don't know which change caused this exaclty (could
have been something from Hristo or Damencho ) so we need to
investigate.

Does it break anything other than the multiple instance case?

Hristo can you try checking this out at the end of next week?

On Tue, Apr 29, 2014 at 11:21 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Hristo,

This is still there, and it is still extremely annoying. Could please,
please take a look at that?

Ingo

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of

Ingo

Bauersachs
Sent: Dienstag, 8. April 2014 22:17
To: 'Jitsi Developers'
Subject: Re: [jitsi-dev] JVM hang when starting second Jitsi instance (on
Windows)
So, by trial and error: renaming/deleting jmsoutlookaddrbook.dll makes the
problem disappear.

-> Hristo, something went seriously wrong with your recent updates to
integrate the calendar. Could you please have a look at that?

Ingo

dev-bounces@jitsi.org wrote on auersachs: >>>> Windows) >>>> Hey >>>> >>>> I have a VERY strange behavior: as soon as I launch a second instance of

Jitsi, the one that was launched first completely hangs. I cannot even
create a thread dump (JVisualVM starts to hang too as soon as I try to
attach to the hanging Jitsi), nor is there a JVM crash log.

This has never been a problem and I'm wondering if anyone has seen
something similar?

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hello,

We have just committed a fix for the issue.

The problem was that we are passing an address for the object that will
handle the results from Outlook to the jmsoutlookaddrbookcomserver*.exe(
external Jitsi process that handles the communication with Outlook). But
the second Jitsi instance is sending the address to the
jmsoutlookaddrbookcomserver*.exe that is started by the first instance of
Jitsi. Then the jmsoutlookaddrbookcomserver*.exe sends the address to the
first Jitsi instance and when it tries to use it Jitsi crashes.

In general when two or more Jitsi instances are started we are starting one
more process for each instance which handles the communication with Outlook
and returns searched results to the Jitsi instance. Every process creates
COM Server to receive the requests for Outlook contacts and every Jitsi
instance creates COM server to receive the results of the search. We are
using CoCreateInstance function to access the COM servers and it seems we
are getting the COM servers only for the first Jitsi instance when we are
calling the function from the second instance. We added a check that
prevents starting additional COM servers for the second instance if we
already have started COM servers from the first instance of Jitsi. This
fixes the problem with Jitsi crashes but the Outlook integration doesn't
work for the second instance of Jitsi.

Anybody who wants to contribute with a patch that fixes the issue with the
Outlook integration that is not working for multiple Jitsi instances is
welcomed!

Regards,
Hristo.

···

On Thu, May 1, 2014 at 2:50 PM, Hristo Terezov <hristo@jitsi.org> wrote:

I’ll check it.

On Apr 30, 2014, at 10:46 PM, Emil Ivov <emcho@jitsi.org> wrote:

> So the thing is we don't know which change caused this exaclty (could
> have been something from Hristo or Damencho ) so we need to
> investigate.
>
> Does it break anything other than the multiple instance case?
>
> Hristo can you try checking this out at the end of next week?
>
> On Tue, Apr 29, 2014 at 11:21 PM, Ingo Bauersachs <ingo@jitsi.org> > wrote:
>> Hristo,
>>
>> This is still there, and it is still extremely annoying. Could please,
>> please take a look at that?
>>
>> Ingo
>>
>>> -----Original Message-----
>>> From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf
Of
>> Ingo
>>> Bauersachs
>>> Sent: Dienstag, 8. April 2014 22:17
>>> To: 'Jitsi Developers'
>>> Subject: Re: [jitsi-dev] JVM hang when starting second Jitsi instance
(on
>>> Windows)
>>> So, by trial and error: renaming/deleting jmsoutlookaddrbook.dll makes
the
>>> problem disappear.
>>>
>>> -> Hristo, something went seriously wrong with your recent updates to
>>> integrate the calendar. Could you please have a look at that?
>>>
>>> Ingo
>>>
>>> dev-bounces@jitsi.org wrote on auersachs: > >>>> Windows) > >>>> Hey > >>>> > >>>> I have a VERY strange behavior: as soon as I launch a second instance
of
>>>> Jitsi, the one that was launched first completely hangs. I cannot even
>>>> create a thread dump (JVisualVM starts to hang too as soon as I try to
>>>> attach to the hanging Jitsi), nor is there a JVM crash log.
>>>>
>>>> This has never been a problem and I'm wondering if anyone has seen
>>>> something similar?
>>>>
>>>> Ingo
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> --
> https://jitsi.org
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

--
Regards,
Hristo.


#5

Hello jitsi dev team,

do you have any plans on supporting connected standby (i.e. ring/wake from sleep on incoming VoIP calls)?

The new Win 8.1 tablets like the HP ElitePad 1000 G2 already support this in hardware and Skype already supports it in software (source: http://forum.tabletpcreview.com/hewlett-packard/61272-new-propad-600-elitepad-1000-a-11.html#post381074)

I think together with Jitsi as SIP client this would really be a killer feature, since your tablet then could replace your home phone and in some scenarios even your smart phone! (Well nearly... there is still the problem with emergency calls and VoIP.)

Would it be hard to implement? As far as I understand it, the API for requesting a "hardware slot" to configure wake scenarios can be found at http://msdn.microsoft.com/en-us/library/windows/apps/hh701088.aspx with a code example here: http://msdn.microsoft.com/en-us/library/windows/apps/xaml/jj710181.aspx (search for "RequestHardwareSlot"). It seems to work with any high level TCP/IP connection, but I am no expert here...

Thanks for your time,
Michael.


#6

Hey

We have just committed a fix for the issue.

Thanks, I can confirm this works.

The problem was that we are passing an address for the object that will
handle the results from Outlook to the jmsoutlookaddrbookcomserver*.exe(
external Jitsi process that handles the communication with Outlook). But the
second Jitsi instance is sending the address to the
jmsoutlookaddrbookcomserver*.exe that is started by the first instance of
Jitsi. Then the jmsoutlookaddrbookcomserver*.exe sends the address to the
first Jitsi instance and when it tries to use it Jitsi crashes.

In general when two or more Jitsi instances are started we are starting one
more process for each instance which handles the communication with Outlook
and returns searched results to the Jitsi instance. Every process creates COM
Server to receive the requests for Outlook contacts and every Jitsi instance
creates COM server to receive the results of the search. We are using
CoCreateInstance function to access the COM servers and it seems we are
getting the COM servers only for the first Jitsi instance when we are calling
the function from the second instance. We added a check that prevents
starting additional COM servers for the second instance if we already have
started COM servers from the first instance of Jitsi. This fixes the problem
with Jitsi crashes but the Outlook integration doesn't work for the second
instance of Jitsi.

Anybody who wants to contribute with a patch that fixes the issue with
the Outlook integration that is not working for multiple Jitsi instances
is welcomed!

My COM knowledge is limited, but AFAIK there should only be one COM-Server where the multiple Jitsi instances would connect to. However, I think it's not really necessary to support multiple running instances connecting to Outlook at the same time. Simply being able to launch a second dev-instance besides the regular one with crashing the first (which is the case now) is fine for me.

Regards,
Hristo.

Ingo


#7

do you have any plans on supporting connected standby (i.e. ring/wake from
sleep on incoming VoIP calls)?

I can't speak for BlueJimp, but so far, no.

The new Win 8.1 tablets like the HP ElitePad 1000 G2 already support
this in hardware and Skype already supports it in software (source:
http://forum.tabletpcreview.com/hewlett-packard/61272-new-propad-600-
elitepad-1000-a-11.html#post381074)

I think together with Jitsi as SIP client this would really be a killer
feature, since your tablet then could replace your home phone and in some
scenarios even your smart phone! (Well nearly... there is still the problem
with emergency calls and VoIP.)

Would it be hard to implement?

Yes.

As far as I understand it, the API for
requesting a "hardware slot" to configure wake scenarios can be found at
http://msdn.microsoft.com/en-us/library/windows/apps/hh701088.aspx with a
code example here: http://msdn.microsoft.com/en-
us/library/windows/apps/xaml/jj710181.aspx (search for
"RequestHardwareSlot"). It seems to work with any high level TCP/IP
connection, but I am no expert here...

The APIs you mentioned are for Windows Store Apps - which are written in .NET or the whatever-it-really-is WinRT. Jitsi is a desktop application based on Java, which makes any native interaction more difficult. While probably not impossible, it would be quite a project. See the following links for more information:

http://msdn.microsoft.com/en-us/library/windows/hardware/dn481223(v=vs.85).aspx#desktop
http://msdn.microsoft.com/en-us/library/windows/hardware/hh848040(v=vs.85).aspx

Thanks for your time,
Michael.

Ingo


#8

I can’t speak for BlueJimp, but so far, no.

      Okay, sad to hear, but thanks for looking into it and for your fast response.

See the following links for more information:

      Thanks for the links. I have read the Desktop Activity Moderator article. I also understand why it would be hard to interface natively to Windows.Networking.Sockets.Pushenabledapplication.dll and wrap ControlChannelTrigger (and all the associated objects) from Java.

Maybe it would be easier to follow a ** mini launcher concept?:** I.e. a small app that uses the existing Windows API to just listen for incoming VoIP calls. Once there is a call, it would wake the system and immediately forward the call to the running Jitsi desktop program.

    This would probably also be more pure from a platform independence perspective. Of course, this concept depends communication between a metro app and a real desktop program and I am not sure if Windows and the different runtimes allow this easily (if no direct inter-process communication is viable, a mini client/server concept via a localhost socket could do the trick). As a side effect, the launcher app might be able to collect more attention for Jitsi from Windows Store users.

    However, I get the picture that it unfortunately isn't as straight-forward as just registering a hardware slot before sleep (as I initially thought it would be with help of ControlChannelTrigger; sorry).

Michael.

···

http://msdn.microsoft.com/en-us/library/windows/hardware/dn481223(v=vs.85).aspx#desktophttp://msdn.microsoft.com/en-us/library/windows/hardware/hh848040(v=vs.85).aspx


#9

I can't speak for BlueJimp, but so far, no.

Okay, sad to hear, but thanks for looking into it and for your fast response.

We don't have resources to look into this. Contributions however are always most welcome.

See the following links for more information: http://msdn.microsoft.com/en-us/library/windows/hardware/dn481223(v=vs.85).aspx#desktop http://msdn.microsoft.com/en-us/library/windows/hardware/hh848040(v=vs.85).aspx

Thanks for the links. I have read the Desktop Activity Moderator article. I also understand why it would be hard to interface natively to Windows.Networking.Sockets.Pushenabledapplication.dll and wrap ControlChannelTrigger (and all the associated objects) from Java.

Maybe it would be easier to follow a mini launcher concept?: I.e. a small app that uses the existing Windows API to just listen for incoming VoIP calls. Once there is a call, it would wake the system and immediately forward the call to the running Jitsi desktop program.

This would probably also be more pure from a platform independence perspective. Of course, this concept depends communication between a metro app and a real desktop program and I am not sure if Windows and the different runtimes allow this easily (if no direct inter-process communication is viable, a mini client/server concept via a localhost socket could do the trick).

Ingerprocess communication between Metro and Desktop apps is completely impossible. Even with the socket idea. At least it was when I last tried this and I think there are rumors to loosen that restriction with the upcoming Windows 9.

The other problem is that this mini-launcher would need to handle the socket connection to the SIP server, dealing with registrations and keep-alives.

As a side effect, the launcher app might be able to collect more attention for Jitsi from Windows Store users.

However, I get the picture that it unfortunately isn't as straight-forward as just registering a hardware slot before sleep (as I initially thought it would be with help of ControlChannelTrigger; sorry).
Michael.

Ingo

···

Le 14.05.2014 à 09:02, "Grau.Info+Coding@gmail.com" <Grau.Info+Coding@gmail.com> a écrit :