artadmin fills /tmp during dump

[damonjebb]

It would appear that artadmin is not very well behaved in its use of the /tmp folder during a dump of a full repository.  I have a repo that has reached 40GB (under 1.2.5rc5) and am trying to export. I started to get messages like ...

Failed to export jcr file: 'path/to/file'. Skipping file

I have worked out that this is because the /tmp folder (2.5GB partition of its own) is filling up and artadmin can't write it's temporary files to it.

So I tried setting the environment variable 'TMPDIR' to point somewhere where there is plenty of space, but artadmin appears not to honour it as it kept right on writing its temp files in the /tmp folder!

I have managed to keep the export running by manually removing files of the form bin[\d]*.tmp from /tmp during the dump process.  This is not very satisfactory though.

My question - has anyone seen this behaviour already ( a search of this forum did not seem to find any discussion of it)?  Is there a better way of keeping a large repo dump going with a much smaller /tmp folder?

Thanks
Damon

[Yoav Landman]

Hi,

I don't believe TMPDIR is honored by the JVM, so you have to add -Djava.io.tmpdir=/otherTmpPath to the script launching the artadmin VM.
Which Artifactory version artadmin command are you using BTW?

Thanks,

Yoav

On Fri, Jun 26, 2009 at 6:15 PM, damonjebb <djebb@...> wrote:

It would appear that artadmin is not very well behaved in its use of the /tmp
folder during a dump of a full repository.  I have a repo that has reached
40GB (under 1.2.5rc5) and am trying to export. I started to get messages
like ...

Failed to export jcr file: 'path/to/file'. Skipping file

I have worked out that this is because the /tmp folder (2.5GB partition of
its own) is filling up and artadmin can't write it's temporary files to it.

So I tried setting the environment variable 'TMPDIR' to point somewhere
where there is plenty of space, but artadmin appears not to honour it as it
kept right on writing its temp files in the /tmp folder!

I have managed to keep the export running by manually removing files of the
form bin[\d]*.tmp from /tmp during the dump process.  This is not very
satisfactory though.

My question - has anyone seen this behaviour already ( a search of this
forum did not seem to find any discussion of it)?  Is there a better way of
keeping a large repo dump going with a much smaller /tmp folder?

Thanks
Damon
--
View this message in context: http://www.nabble.com/artadmin-fills--tmp-during-dump-tp24222109p24222109.html
Sent from the Artifactory-Users mailing list archive at Nabble.com.


------------------------------------------------------------------------------
_______________________________________________
Artifactory-users mailing list
Artifactory-users@...
https://lists.sourceforge.net/lists/listinfo/artifactory-users

------------------------------------------------------------------------------

_______________________________________________
Artifactory-users mailing list
Artifactory-users@...
https://lists.sourceforge.net/lists/listinfo/artifactory-users

[damonjebb]

Yoav Landman wrote:

I don't believe TMPDIR is honored by the JVM, so you have to add
-Djava.io.tmpdir=/otherTmpPath to the script launching the artadmin VM.

I'm not using a wrapper script to run artadmin, just executing it directly from the command line - do you think it would be better therefore to create a wrapper script that can do this?

Yoav Landman wrote:

Which Artifactory version artadmin command are you using BTW?

I'm using artadmin from 2.0.6, which I am intending to upgrade to.

Thanks
Damon

[Yoav Landman]

Hi Damon,

There's no need in using a wrapper script - you can either set the JAVA_OPTIONS env variable to "-Djava.io.tmpdir=/otherTmpPath" before running the artadmin command or add it directly to the last line of the artadmin script (in the exec command, immediately after $JAVA_OPTIONS).
With 2.0.x and above we no longer require a repository dump in order to upgrade to newer verisions, BTW - you just update the jars and that's it.

HTH,

Yoav

On Sun, Jun 28, 2009 at 6:41 PM, damonjebb <djebb@...> wrote:

Yoav  Landman wrote:
>
> I don't believe TMPDIR is honored by the JVM, so you have to add
> -Djava.io.tmpdir=/otherTmpPath to the script launching the artadmin VM.
>

I'm not using a wrapper script to run artadmin, just executing it directly
from the command line - do you think it would be better therefore to create
a wrapper script that can do this?

Yoav  Landman wrote:
>
> Which Artifactory version artadmin command are you using BTW?
>

I'm using artadmin from 2.0.6, which I am intending to upgrade to.

Thanks
Damon
--
View this message in context: http://www.nabble.com/artadmin-fills--tmp-during-dump-tp24222109p24242596.html

Sent from the Artifactory-Users mailing list archive at Nabble.com.


------------------------------------------------------------------------------
_______________________________________________
Artifactory-users mailing list
Artifactory-users@...
https://lists.sourceforge.net/lists/listinfo/artifactory-users

------------------------------------------------------------------------------

_______________________________________________
Artifactory-users mailing list
Artifactory-users@...
https://lists.sourceforge.net/lists/listinfo/artifactory-users

[damonjebb]

Yoav Landman wrote:

There's no need in using a wrapper script - you can either set the
JAVA_OPTIONS env variable to "-Djava.io.tmpdir=/otherTmpPath" before running
the artadmin command or add it directly to the last line of the artadmin
script (in the exec command, immediately after $JAVA_OPTIONS).

Yes, thanks, I worked this one out when I read through the artadmin script and have now successfully exported the repositories.

Yoav Landman wrote:

With 2.0.x and above we no longer require a repository dump in order to
upgrade to newer verisions, BTW - you just update the jars and that's it.

 

This is not what the upgrade instructions in the manual say - is that only from later versions than my 1.2.5-rc5?

Thanks
Damon

[damonjebb]

Yoav Landman wrote:

There's no need in using a wrapper script - you can either set the
JAVA_OPTIONS env variable to "-Djava.io.tmpdir=/otherTmpPath" before running
the artadmin command or add it directly to the last line of the artadmin
script (in the exec command, immediately after $JAVA_OPTIONS).

Yes, thanks, I worked this one out when I read through the artadmin script and have now successfully exported the repositories.

Yoav Landman wrote:

With 2.0.x and above we no longer require a repository dump in order to
upgrade to newer verisions, BTW - you just update the jars and that's it.

 

This is not what the upgrade instructions in the manual say - is that only from later versions than my 1.2.5-rc5?

Thanks
Damon

[Yoav Landman]

On Mon, Jun 29, 2009 at 12:40 PM, damonjebb <djebb@...> wrote:

Yoav  Landman wrote:
>
> There's no need in using a wrapper script - you can either set the
> JAVA_OPTIONS env variable to "-Djava.io.tmpdir=/otherTmpPath" before
> running
> the artadmin command or add it directly to the last line of the artadmin
> script (in the exec command, immediately after $JAVA_OPTIONS).
>

Yes, thanks, I worked this one out when I read through the artadmin script
and have now successfully exported the repositories.

Yoav  Landman wrote:
>
>
> With 2.0.x and above we no longer require a repository dump in order to
> upgrade to newer verisions, BTW - you just update the jars and that's it.
>
>

This is not what the upgrade instructions in the manual
http://wiki.jfrog.org/confluence/display/RTF/Upgrading+Artifactory say  - is
that only from later versions than my 1.2.5-rc5?

Exactly. Like I said - with 2.0.x and above (the list of supported versions is under the header of the section that refers to upgrading to 2.0.x).

Thanks
Damon

--
View this message in context: http://www.nabble.com/artadmin-fills--tmp-during-dump-tp24222109p24251150.html

Sent from the Artifactory-Users mailing list archive at Nabble.com.


------------------------------------------------------------------------------
_______________________________________________
Artifactory-users mailing list
Artifactory-users@...
https://lists.sourceforge.net/lists/listinfo/artifactory-users

------------------------------------------------------------------------------

_______________________________________________
Artifactory-users mailing list
Artifactory-users@...
https://lists.sourceforge.net/lists/listinfo/artifactory-users

[damonjebb]

Yoav Landman wrote:

Exactly. Like I said - with 2.0.x and above (the list of supported versions
is under the header of the section that refers to upgrading to 2.0.x).

OK, my misunderstanding of what you were saying - so in future when upgrading from 2.0.6 it will not be necessary to to anything more than replace the jar files.

Thanks
Damon