Problem committing added file

[Andrew Aucott-2]

we have an issue committing when a file has been scheduled to be added to a working copy. 

the file is over 100mb (although im not sure how relevant that is) and the working copy resides on a network share accessed via a mapped drive in windows xp.

this is the stack trace received when performing the commit:

org.tmatesoft.svn.core.SVNException: svn: Commit failed (details follow):

svn: Cannot copy file

'I:\NGPF\NGPF_HPTClearance\Studies\02_ODRailShape\Rotor_Thermal\NGPF_Rotor_00\thermal_results.rth' to

'I:\NGPF\NGPF_HPTClearance\Studies\02_ODRailShape\Rotor_Thermal\NGPF_Rotor_00\.svn\tmp\text-base\thermal_results.rth.svn-base': 

Insufficient system resources exist to complete the requested service 

at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:49) 

at org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:582)

at org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:549)

searching around i came across the following sun bug report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4938442. it seems to describe the behavior and i notice browsing svnkit that FileChannels are used when committing added files.

Perhaps you could try and replicate the issue? its possible to replicate the commit needs to happen on a background thread.

Thanks

Andrew

[Alexander Kitaev-3]

Hello Andrew,

 > searching around i came across the following sun bug
 > report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4938442. it
 > seems to describe the behavior and i notice browsing svnkit that
 > FileChannels are used when committing added files.
I read there that the problem could be workarounded by not using NIO. We
use it for file copying and some other operations. What we could do is
add an option not to use NIO (and use ordinary buffered copy instead)
for the next bugfix release.

Also, I'd recommend you to try newer version of JDK - may be this
problem is resolved there.

Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!

Andrew Aucott wrote:

> we have an issue committing when a file has been scheduled to be added
> to a working copy.
> the file is over 100mb (although im not sure how relevant that is) and
> the working copy resides on a network share accessed via a mapped drive
> in windows xp.
>
> this is the stack trace received when performing the commit:
> org.tmatesoft.svn.core.SVNException: svn: Commit failed (details follow):
> svn: Cannot copy file
> 'I:\NGPF\NGPF_HPTClearance\Studies\02_ODRailShape\Rotor_Thermal\NGPF_Rotor_00\thermal_results.rth'
> to
> 'I:\NGPF\NGPF_HPTClearance\Studies\02_ODRailShape\Rotor_Thermal\NGPF_Rotor_00\.svn\tmp\text-base\thermal_results.rth.svn-base':
> Insufficient system resources exist to complete the requested service
> at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:49)
> at org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:582)
> at org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:549)
>
> searching around i came across the following sun bug
> report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4938442. it
> seems to describe the behavior and i notice browsing svnkit that
> FileChannels are used when committing added files.
>
> Perhaps you could try and replicate the issue? its possible to replicate
> the commit needs to happen on a background thread.
>
> Thanks
> Andrew

[Andrew Aucott-2]

Hi Alexander

I tried later versions of the JDK but still the same problem.

I then tried to reduce the size of the number of bytes in each  
transfer call and this worked ok in my testing. I reduced the number  
of bytes from 1024mb to 32mb, granted there are more calls and it  
probably wont be as efficient but it did work without any exceptions.  
This work around was suggested in the bug report.

At the bottom of the bug report there is a code example for another  
work around that may be preferable. It first attempts the copy using  
NIO and then if that fails reverts to a regular buffered copy. If you  
would like me to submit the code for this let me know.

Thanks for your support.
Andrew


On 7 Aug 2007, at 19:24, Alexander Kitaev wrote:

> > searching around i came across the following sun bug
> > report http://bugs.sun.com/bugdatabase/view_bug.do?
> bug_id=4938442. it
> > seems to describe the behavior and i notice browsing svnkit that
> > FileChannels are used when committing added files.
> I read there that the problem could be workarounded by not using  
> NIO. We use it for file copying and some other operations. What we  
> could do is add an option not to use NIO (and use ordinary buffered  
> copy instead) for the next bugfix release.
>
> Also, I'd recommend you to try newer version of JDK - may be this  
> problem is resolved there.

[Alexander Kitaev-3]

Hello Andrew,

 > At the bottom of the bug report there is a code example for another work
 > around that may be preferable. It first attempts the copy using NIO and
 > then if that fails reverts to a regular buffered copy. If you would like
 > me to submit the code for this let me know.
I've missed this code example, sorry. I've added more or less the same
code to 1.1.x branch at revision 3330. Could you please try it?

Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!

Andrew Aucott wrote:

> Hi Alexander
>
> I tried later versions of the JDK but still the same problem.
>
> I then tried to reduce the size of the number of bytes in each transfer
> call and this worked ok in my testing. I reduced the number of bytes
> from 1024mb to 32mb, granted there are more calls and it probably wont
> be as efficient but it did work without any exceptions. This work around
> was suggested in the bug report.
>
> At the bottom of the bug report there is a code example for another work
> around that may be preferable. It first attempts the copy using NIO and
> then if that fails reverts to a regular buffered copy. If you would like
> me to submit the code for this let me know.
>
> Thanks for your support.
> Andrew
>
>
> On 7 Aug 2007, at 19:24, Alexander Kitaev wrote:
>> > searching around i came across the following sun bug
>> > report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4938442. it
>> > seems to describe the behavior and i notice browsing svnkit that
>> > FileChannels are used when committing added files.
>> I read there that the problem could be workarounded by not using NIO.
>> We use it for file copying and some other operations. What we could do
>> is add an option not to use NIO (and use ordinary buffered copy
>> instead) for the next bugfix release.
>>
>> Also, I'd recommend you to try newer version of JDK - may be this
>> problem is resolved there.
>

[Andrew Aucott-2]

Hi Alexander,

Although the file seems to get copied okay via the secondary method  
the commit fails. Looking at the code once the file is copied  
SVNErrorManager.error is still called and therefore the commit fails.

Perhaps the error should be cleared when inside the second copy method?

Andrew

On 9 Aug 2007, at 14:36, Alexander Kitaev wrote:

> Hello Andrew,
>
> > At the bottom of the bug report there is a code example for  
> another work
> > around that may be preferable. It first attempts the copy using  
> NIO and
> > then if that fails reverts to a regular buffered copy. If you  
> would like
> > me to submit the code for this let me know.
> I've missed this code example, sorry. I've added more or less the  
> same code to 1.1.x branch at revision 3330. Could you please try it?
>
> Alexander Kitaev,
> TMate Software,
> http://svnkit.com/ - Java [Sub]Versioning Library!
>
> Andrew Aucott wrote:
>> Hi Alexander
>> I tried later versions of the JDK but still the same problem.
>> I then tried to reduce the size of the number of bytes in each  
>> transfer call and this worked ok in my testing. I reduced the  
>> number of bytes from 1024mb to 32mb, granted there are more calls  
>> and it probably wont be as efficient but it did work without any  
>> exceptions. This work around was suggested in the bug report.
>> At the bottom of the bug report there is a code example for  
>> another work around that may be preferable. It first attempts the  
>> copy using NIO and then if that fails reverts to a regular  
>> buffered copy. If you would like me to submit the code for this  
>> let me know.
>> Thanks for your support.
>> Andrew
>> On 7 Aug 2007, at 19:24, Alexander Kitaev wrote:
>>> > searching around i came across the following sun bug
>>> > report http://bugs.sun.com/bugdatabase/view_bug.do?
>>> bug_id=4938442. it
>>> > seems to describe the behavior and i notice browsing svnkit that
>>> > FileChannels are used when committing added files.
>>> I read there that the problem could be workarounded by not using  
>>> NIO. We use it for file copying and some other operations. What  
>>> we could do is add an option not to use NIO (and use ordinary  
>>> buffered copy instead) for the next bugfix release.
>>>
>>> Also, I'd recommend you to try newer version of JDK - may be this  
>>> problem is resolved there.

[Alexander Kitaev-3]

Hello Andrew,

 > Although the file seems to get copied okay via the secondary method the
 > commit fails. Looking at the code once the file is copied
 > SVNErrorManager.error is still called and therefore the commit fails.
 >
 > Perhaps the error should be cleared when inside the second copy method?
Thank you for pointing to this. I've just committed the fix (branch
1.1.x, rev 3345).

Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!

Andrew Aucott wrote:

> Hi Alexander,
>
> Although the file seems to get copied okay via the secondary method the
> commit fails. Looking at the code once the file is copied
> SVNErrorManager.error is still called and therefore the commit fails.
>
> Perhaps the error should be cleared when inside the second copy method?
>
> Andrew
>
> On 9 Aug 2007, at 14:36, Alexander Kitaev wrote:
>
>> Hello Andrew,
>>
>> > At the bottom of the bug report there is a code example for another
>> work
>> > around that may be preferable. It first attempts the copy using NIO and
>> > then if that fails reverts to a regular buffered copy. If you would
>> like
>> > me to submit the code for this let me know.
>> I've missed this code example, sorry. I've added more or less the same
>> code to 1.1.x branch at revision 3330. Could you please try it?
>>
>> Alexander Kitaev,
>> TMate Software,
>> http://svnkit.com/ - Java [Sub]Versioning Library!
>>
>> Andrew Aucott wrote:
>>> Hi Alexander
>>> I tried later versions of the JDK but still the same problem.
>>> I then tried to reduce the size of the number of bytes in each
>>> transfer call and this worked ok in my testing. I reduced the number
>>> of bytes from 1024mb to 32mb, granted there are more calls and it
>>> probably wont be as efficient but it did work without any exceptions.
>>> This work around was suggested in the bug report.
>>> At the bottom of the bug report there is a code example for another
>>> work around that may be preferable. It first attempts the copy using
>>> NIO and then if that fails reverts to a regular buffered copy. If you
>>> would like me to submit the code for this let me know.
>>> Thanks for your support.
>>> Andrew
>>> On 7 Aug 2007, at 19:24, Alexander Kitaev wrote:
>>>> > searching around i came across the following sun bug
>>>> > report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4938442. it
>>>> > seems to describe the behavior and i notice browsing svnkit that
>>>> > FileChannels are used when committing added files.
>>>> I read there that the problem could be workarounded by not using
>>>> NIO. We use it for file copying and some other operations. What we
>>>> could do is add an option not to use NIO (and use ordinary buffered
>>>> copy instead) for the next bugfix release.
>>>>
>>>> Also, I'd recommend you to try newer version of JDK - may be this
>>>> problem is resolved there.
>
>