hi jozef
Well I had to increase maximum heap size for both client and tomcat
server in order to be able to send 20mb binary property, and it was
damn slow. I think most of the problem was by this base64 conversion.
probably the easiest (least effort) solution would be
to have an alternative im
Hi Angela,
On 1/9/08, Angela Schreiber <[EMAIL PROTECTED]> wrote:
>
> can you open an issue for that?
>
Done, http://issues.apache.org/jira/browse/JCR-1300
Best,
Jozef
Hi,
I would like to ask about the status of this issue.
Is there some plan/roadmap (no matter how vague)? How do you see it in
terms of time and resources?
Sorry if it seems I'm pressing on you, I'm not :). I just want to know
it in order to be able plan things in my project.
Thank you in advan
hi jozef
I would like to ask about the status of this issue.
Is there some plan/roadmap (no matter how vague)? How do you see it in
terms of time and resources?
this issue doesn't have high priority for me.
what i can offer you is:
- quickly hack it in for non-multivalued properties.
- leave
Hi Angela,
Thank you for your response!
> > I would like to ask about the status of this issue.
> > Is there some plan/roadmap (no matter how vague)? How do you see it in
> > terms of time and resources?
>
> this issue doesn't have high priority for me.
> what i can offer you is:
>
> - quickly ha
Hi All,
Problem 1:
org.apache.jackrabbit.jcr2spi.WorkspaceManager.execute(ChangeLog changelog)
has try{} finally{} block without catch.
It happened to me that both try and finally block thrown an exception.
Of course exception from try{} was lost, and I got misleaded :)
Problem 2:
I'm trying to
hi jozef
Jozef Wagner wrote:
So, should I just set bigger heap for jvm or current spi2dav prototype
does not support large data? I need to send files as large as 200MB.
you are basically asking whether spi2dav should support large
data, right? so i'd say yes... but i wouldn't be surprised
if
Hi,
> a possible way improve this would be to make usage of
> the global data store (JCR-926)
That would be a solution. The idea is to avoid temporary copies of the
data, and persist large objects as early as possible. I'm not sure if
the data store should be used in the Jackrabbit SPI client (it
Thomas Mueller wrote:
Hi,
a possible way improve this would be to make usage of
the global data store (JCR-926)
That would be a solution. The idea is to avoid temporary copies of the
data, and persist large objects as early as possible. I'm not sure if
the data store should be used in the Jac
Hi Jozef,
Jozef Wagner wrote:
Problem 1:
org.apache.jackrabbit.jcr2spi.WorkspaceManager.execute(ChangeLog changelog)
has try{} finally{} block without catch.
It happened to me that both try and finally block thrown an exception.
Of course exception from try{} was lost, and I got misleaded :)
Hi,
it's the method near the end of the file:
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/WorkspaceManager.java?view=markup
it is thrown by service.submit(batch); and it is constraint exception,
about not supplying all required pro
Hi Jozef,
thank you for the info. I've created a jira issue:
https://issues.apache.org/jira/browse/JCR-1296
regards
marcel
Jozef Wagner wrote:
Hi,
it's the method near the end of the file:
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit
Hi,
Well I had to increase maximum heap size for both client and tomcat
server in order to be able to send 20mb binary property, and it was
damn slow. I think most of the problem was by this base64 conversion.
That is not good of course and I have to sind a solution pretty soon.
When I use norma
13 matches
Mail list logo
