[jitsi-dev] Moving logs on Windows to LocalAppData


#1

Hey

At work, we use "folder redirection" and hence %appdata% points to a
directory on a file server. This causes problems with Jitsi, as it
a) constantly writes the .log and .pcap over the network
b) leaves files open and hence prevents standby

The cache files created by Felix in the sip-communicator.bin directory are
equally bad. Even worse, if two computers had different versions of Jitsi
installed, the shared cache can confuse Felix to death.

Are there any objections that I move these to %localappdata%\Jitsi\ (which
usually expands to c:\users\username\AppData\local\Jitsi)?

Ingo


#2

I wouldn't say I object but:

We'd need to make sure that existing installations continue working (and we already have some code handling legacy cases there: .sip-communicator, SIP Communicator and Jitsi directories).

Either that or we'd need to add code that migrates the directory (but this could be even a deeper pitfall).

Do you have a plan?

Emil

···

On 21.06.13, 00:06, Ingo Bauersachs wrote:

Hey

At work, we use "folder redirection" and hence %appdata% points to a
directory on a file server. This causes problems with Jitsi, as it
a) constantly writes the .log and .pcap over the network
b) leaves files open and hence prevents standby

The cache files created by Felix in the sip-communicator.bin directory are
equally bad. Even worse, if two computers had different versions of Jitsi
installed, the shared cache can confuse Felix to death.

Are there any objections that I move these to %localappdata%\Jitsi\ (which
usually expands to c:\users\username\AppData\local\Jitsi)?

--
https://jitsi.org


#3

Vote for this change...

···

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Ingo Bauersachs
Sent: 20 June 2013 23:07
To: 'Jitsi Developers'
Subject: [jitsi-dev] Moving logs on Windows to LocalAppData

Hey

At work, we use "folder redirection" and hence %appdata% points to a directory on a file server. This causes problems with Jitsi, as it
a) constantly writes the .log and .pcap over the network
b) leaves files open and hence prevents standby

The cache files created by Felix in the sip-communicator.bin directory are equally bad. Even worse, if two computers had different versions of Jitsi installed, the shared cache can confuse Felix to death.

Are there any objections that I move these to %localappdata%\Jitsi\ (which usually expands to c:\users\username\AppData\local\Jitsi)?

Ingo

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


#4

At work, we use "folder redirection" and hence %appdata% points to a
directory on a file server. This causes problems with Jitsi, as it
a) constantly writes the .log and .pcap over the network
b) leaves files open and hence prevents standby

The cache files created by Felix in the sip-communicator.bin directory are
equally bad. Even worse, if two computers had different versions of Jitsi
installed, the shared cache can confuse Felix to death.

Are there any objections that I move these to %localappdata%\Jitsi\ (which
usually expands to c:\users\username\AppData\local\Jitsi)?

I finally found the time to work on this, the result is attached. Basically,
I modified the FileAccessService to demand a second parameter on
getPrivatePersistentFile/Directory: a FileCategory to classify the file.
There are 3 options
- PROFILE: configuration data, message history, contacts, etc.
- CACHE: avatars, downloaded spelling dictionaries, the FMJ registry, etc.
- LOG: application logs (.pcaps, .logs)

All calls to getPrivatePersistentFile/Directory are modified to include this
classification.

- On Windows, application logs and cached data now go %localappdata%\Jitsi
if the environment variable exists, otherwise the folder follows PROFILE,
which is what we currently use.
- On OSX, the application logs go to the folder suggested by Apple
(~/Library/Logs/Jitsi)
- There is no change for Unix

Data present at the current directory will remain there, but will no longer
be used. (The reason to not delete it is that I didn't want to clutter the
launcher class stuff created from all the various components. If this is
desired to avoid confusion (especially with regard to old logs), I'll add
this if you don't mind the clutter.)

Any objections before I commit this?

Ingo

0001-Add-a-classification-for-persistent-files.patch (21.5 KB)

0001-Use-temporary-file-for-XMPP-server-list.patch (4.73 KB)

0002-Use-separate-dirs-for-application-logs-cache-and-con.patch (33.5 KB)


#5

At work, we use "folder redirection" and hence %appdata% points to a
directory on a file server. This causes problems with Jitsi, as it
a) constantly writes the .log and .pcap over the network
b) leaves files open and hence prevents standby

The cache files created by Felix in the sip-communicator.bin directory

are

equally bad. Even worse, if two computers had different versions of Jitsi
installed, the shared cache can confuse Felix to death.

Are there any objections that I move these to %localappdata%\Jitsi\

(which

usually expands to c:\users\username\AppData\local\Jitsi)?

I wouldn't say I object but:

We'd need to make sure that existing installations continue working (and
we already have some code handling legacy cases there:
.sip-communicator, SIP Communicator and Jitsi directories).

Either that or we'd need to add code that migrates the directory (but
this could be even a deeper pitfall).

Do you have a plan?

As I only wanted to move log-files and auto-created stuff (not the
properties nor the contact list or history) I don't see a reason to really
migrate the stuff other than deleting the affected directories from their
current location (appdata\roaming).

Emil

Ingo


#6

Hi Ingo,

I haven't looked at the patches just thought about the option to
archive logs so users can send them, will this work? Currently the log
folder is obtained like this:
LOGGING_DIR_NAME = "log";
LoggingUtilsActivator.getFileAccessService()
                .getPrivatePersistentDirectory(LOGGING_DIR_NAME).listFiles();

Regards
damencho

···

On Tue, Aug 6, 2013 at 7:29 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

At work, we use "folder redirection" and hence %appdata% points to a
directory on a file server. This causes problems with Jitsi, as it
a) constantly writes the .log and .pcap over the network
b) leaves files open and hence prevents standby

The cache files created by Felix in the sip-communicator.bin directory are
equally bad. Even worse, if two computers had different versions of Jitsi
installed, the shared cache can confuse Felix to death.

Are there any objections that I move these to %localappdata%\Jitsi\ (which
usually expands to c:\users\username\AppData\local\Jitsi)?

I finally found the time to work on this, the result is attached. Basically,
I modified the FileAccessService to demand a second parameter on
getPrivatePersistentFile/Directory: a FileCategory to classify the file.
There are 3 options
- PROFILE: configuration data, message history, contacts, etc.
- CACHE: avatars, downloaded spelling dictionaries, the FMJ registry, etc.
- LOG: application logs (.pcaps, .logs)

All calls to getPrivatePersistentFile/Directory are modified to include this
classification.

- On Windows, application logs and cached data now go %localappdata%\Jitsi
if the environment variable exists, otherwise the folder follows PROFILE,
which is what we currently use.
- On OSX, the application logs go to the folder suggested by Apple
(~/Library/Logs/Jitsi)
- There is no change for Unix

Data present at the current directory will remain there, but will no longer
be used. (The reason to not delete it is that I didn't want to clutter the
launcher class stuff created from all the various components. If this is
desired to avoid confusion (especially with regard to old logs), I'll add
this if you don't mind the clutter.)

Any objections before I commit this?

Ingo

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


#7

Thanks Ingo!

inline:

Hi Ingo,

I haven't looked at the patches just thought about the option to
archive logs so users can send them, will this work? Currently the log
folder is obtained like this:
LOGGING_DIR_NAME = "log";
LoggingUtilsActivator.getFileAccessService()
                 .getPrivatePersistentDirectory(LOGGING_DIR_NAME).listFiles();

That's important indeed.

Also, I believe you mentioned on previous occasions that in your environment (server-stored user profiles) you were seeing poor performance because Jitsi was accessing those directories too often.

The thing is that we do that for contact lists and configuration almost as much as we do it for logging. Have you checked that moving the log directory resolves your issue?

This is not an innocuous change so I'd prefer knowing that we are actually resolving problems and not just addressing conventions.

Emil

···

On 06.08.13, 11:37, Damian Minkov wrote:

Regards
damencho

On Tue, Aug 6, 2013 at 7:29 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

At work, we use "folder redirection" and hence %appdata% points to a
directory on a file server. This causes problems with Jitsi, as it
a) constantly writes the .log and .pcap over the network
b) leaves files open and hence prevents standby

The cache files created by Felix in the sip-communicator.bin directory are
equally bad. Even worse, if two computers had different versions of Jitsi
installed, the shared cache can confuse Felix to death.

Are there any objections that I move these to %localappdata%\Jitsi\ (which
usually expands to c:\users\username\AppData\local\Jitsi)?

I finally found the time to work on this, the result is attached. Basically,
I modified the FileAccessService to demand a second parameter on
getPrivatePersistentFile/Directory: a FileCategory to classify the file.
There are 3 options
- PROFILE: configuration data, message history, contacts, etc.
- CACHE: avatars, downloaded spelling dictionaries, the FMJ registry, etc.
- LOG: application logs (.pcaps, .logs)

All calls to getPrivatePersistentFile/Directory are modified to include this
classification.

- On Windows, application logs and cached data now go %localappdata%\Jitsi
if the environment variable exists, otherwise the folder follows PROFILE,
which is what we currently use.
- On OSX, the application logs go to the folder suggested by Apple
(~/Library/Logs/Jitsi)
- There is no change for Unix

Data present at the current directory will remain there, but will no longer
be used. (The reason to not delete it is that I didn't want to clutter the
launcher class stuff created from all the various components. If this is
desired to avoid confusion (especially with regard to old logs), I'll add
this if you don't mind the clutter.)

Any objections before I commit this?

Ingo

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

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

--
https://jitsi.org


#8

I haven't looked at the patches just thought about the option to
archive logs so users can send them, will this work? Currently the log
folder is obtained like this:
LOGGING_DIR_NAME = "log";
LoggingUtilsActivator.getFileAccessService()

.getPrivatePersistentDirectory(LOGGING_DIR_NAME).listFiles();

Sure, that is now getPrivatePersistentDirectory(LOGGING_DIR_NAME,
FileCategory.LOG), so the files are found where they are written to.

Regards
damencho

Ingo


#9

I haven't looked at the patches just thought about the option to
archive logs so users can send them, will this work? Currently the log
folder is obtained like this:
LOGGING_DIR_NAME = "log";
LoggingUtilsActivator.getFileAccessService()

.getPrivatePersistentDirectory(LOGGING_DIR_NAME).listFiles();

That's important indeed.

Covered, see reply to Damian.

Also, I believe you mentioned on previous occasions that in your
environment (server-stored user profiles) you were seeing poor
performance because Jitsi was accessing those directories too often.

Yes. But it's not only the performance: the logfiles are constantly kept
open for writing and thus prevent the computer from entering standby.

The thing is that we do that for contact lists and configuration almost
as much as we do it for logging. Have you checked that moving the log
directory resolves your issue?

It definitely ran much better today. Especially the move of Felix' cache
with its hundreds of files to a local disk improved the startup time
significantly.

This is not an innocuous change so I'd prefer knowing that we are
actually resolving problems and not just addressing conventions.

Emil

Regards
damencho

Ingo


#10

I haven't looked at the patches just thought about the option to
archive logs so users can send them, will this work? Currently the log
folder is obtained like this:
LOGGING_DIR_NAME = "log";
LoggingUtilsActivator.getFileAccessService()

.getPrivatePersistentDirectory(LOGGING_DIR_NAME).listFiles();

Sure, that is now getPrivatePersistentDirectory(LOGGING_DIR_NAME,
FileCategory.LOG), so the files are found where they are written to.

What I meant was: have you tried if this resolved the lag you were experiencing? Does it feel better to the user?

I am specifically wondering if the constant contact list and, to some extent, configuration overwrites could also be causing the same issue.

Emil

···

On 06.08.13, 13:09, Ingo Bauersachs wrote:

Regards
damencho

Ingo

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

--
https://jitsi.org


#11

What I meant was: have you tried if this resolved the lag you were
experiencing? Does it feel better to the user?

One e-mail at a time :wink:

I am specifically wondering if the constant contact list and, to some
extent, configuration overwrites could also be causing the same issue.

The contact list and configuration is also an issue, but:
- it just belongs into APPDATA, so there's nothing I can do for it
- it affects only a couple of users that are allowed to use the "full"
application with large configuration files
- The contact lists are next to empty everywhere

To work around these remaining issues, I'd see two possible solutions:
a) redirect the whole Jitsi config to the local disc (not an option)
b) use a database for the config, such as HSQL

Emil

Ingo