jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francisco Carriedo Scher <fcarrie...@gmail.com>
Subject Re: Exception when operating through load balancer
Date Thu, 03 Nov 2011 11:10:21 GMT
Additionaly to the exceptions that arised when i introduced load balancing
with Nginx (the quoted text below describes the issue) strange behaviour is
taking place now: not finding _existing_ nodes, errors while creating new
nodes and new exceptions appeared even connecting directly with the
repository through its IP address:

2011-11-03 11:57:40.506 WARN  [http-192.168.0.188-8080-1]
JcrRemotingServlet.java:337 */pequeno/jcr:content: mandatory property {
http://www.jcp.org/jcr/1.0}data does not exist*
2011-11-03 12:02:05.009 ERROR [http-192.168.0.188-8080-2]
ExportContextImpl.java:193 ClientAbortException:  *java.net.SocketException:
Broken pipe*

My guessing is that the repository became unconsistent. Any better
interpretation?

Thanks in advance for your attention!


2011/11/2 Francisco Carriedo Scher <fcarriedos@gmail.com>

> Hi there,
>
> i have a clustered JR environment and i operate it from the Java side
> through Webdav. I have deployed three servers that operate in cluster and
> everything went fine until i tried to add a load balancing / fault
> tolerance feature to the design. I am using Nginx as load balancer with the
> webdav module and, despite obtaining correctly the Repository object, some
> operations fail with the following exception:
>
> *javax.jcr.RepositoryException: Request Entity Too Large
>     at org.apache.jackrabbit.spi2dav.**ExceptionConverter.generate(**
> ExceptionConverter.java:113)
>     at org.apache.jackrabbit.spi2dav.**ExceptionConverter.generate(**
> ExceptionConverter.java:49)
>     at org.apache.jackrabbit.**spi2davex.**RepositoryServiceImpl$**
> BatchImpl.start(**RepositoryServiceImpl.java:**457)
>     at org.apache.jackrabbit.**spi2davex.**RepositoryServiceImpl$**
> BatchImpl.access$200(**RepositoryServiceImpl.java:**399)
>     at org.apache.jackrabbit.**spi2davex.**RepositoryServiceImpl.submit(**
> RepositoryServiceImpl.java:**304)
>     at org.apache.jackrabbit.jcr2spi.**WorkspaceManager$**
> OperationVisitorImpl.execute(**WorkspaceManager.java:830)
>     at org.apache.jackrabbit.jcr2spi.**WorkspaceManager$**
> OperationVisitorImpl.access$**500(WorkspaceManager.java:797)
>     at org.apache.jackrabbit.jcr2spi.**WorkspaceManager.execute(**
> WorkspaceManager.java:594)
>     at org.apache.jackrabbit.jcr2spi.**state.SessionItemStateManager.**
> save(SessionItemStateManager.**java:139)
>     at org.apache.jackrabbit.jcr2spi.**ItemImpl.save(ItemImpl.java:**246)
>     at org.apache.jackrabbit.jcr2spi.**SessionImpl.save(SessionImpl.**
> java:328)
>     at com.solaiemes.filerepository.**management.**EmbeddableFileManager.*
> *deleteItem(**EmbeddableFileManager.java:**248)
>     at com.solaiemes.filerepository.**management.**EmbeddableFileManager.*
> *importFile(**EmbeddableFileManager.java:**469)
>     at com.solaiemes.filerepository.**management.**EmbeddableFileManager.*
> *saveFile(**EmbeddableFileManager.java:80)
>     at com.solaiemes.filerepository.**management.RepoShell.main(**
> RepoShell.java:87)
> Caused by: org.apache.jackrabbit.webdav.**DavException: Request Entity
> Too Large
>     at org.apache.jackrabbit.webdav.**client.methods.DavMethodBase.**
> getResponseException(**DavMethodBase.java:172)
>     at org.apache.jackrabbit.webdav.**client.methods.DavMethodBase.**
> checkSuccess(DavMethodBase.**java:181)
>     at org.apache.jackrabbit.**spi2davex.**RepositoryServiceImpl$**
> BatchImpl.start(**RepositoryServiceImpl.java:**453)
>     ... 12 more
> *
> Uploading file operation fails and the initial guessing was that uploading
> files through webdav needs multiple HTTP requests and the load balancer
> would forward each of those to a different repository server. With little
> files (some bytes) and with operations that include just reading it seems
> to work correctly. I added session affinity (sticky session) support to
> Nginx and recompiled it but the same error persists.
>
> Can somebody tell me if my guessing was correct and the error is related
> to the question i suggested?
>
> Thanks in advance for your attention!
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message