Deleting large messages from shared folders not working

[gantscha]

If i try to delete a large Message (larger:50MB) from my local folders everything is fine BUT if i try to delete such a message from a shared folder i get a timeout and nothing happens?!?

Why?

[uxbod]

Does anything show in your Log Files - Zimbra :: Wiki ?

Also, http://www.zimbra.com/forums/announc...r-profile.html please

[gantscha]

It does but it simply tells me that it had a timeout of some sort. The point is that if i delete a message from a share different components of zimbra seem to start as if i delete a message from my local share. For me it seems that moving a large message to or from a shared folder or an external mapped imap account triggers something in zimbra which is really expensive in terms of cpu and ram. I tried to disable the attachments indexing in the default cos but this alone did not help a thing?!?

Any ideas?

Here is the log:

2008-07-24 09:40:27,523 INFO  [btpool0-7] [name=xxx@xxx;mid=3;ip=xxx;ua=zclient/5.0.8_GA_2462.F7;] mailop - Adding Message: id=70840, Message-ID=<479073E6.10009@xxx>, parentId=-1, folderId=3, folderName=Trash.
2008-07-24 09:41:13,105 INFO  [btpool0-3] [name=xxx@xxx;mid=6;ip=172.16.0.40;ua=ZimbraWebClient - FF3.0 (Win)/5.0.8_GA_2462.F7;] SoapEngine - handler exception
com.zimbra.cs.zclient.ZClientException: invoke Read timed out
ExceptionId:btpool0-3:1216885273101:b8c3e4e71a5b1e54
Code:zclient.IO_ERROR
        at com.zimbra.cs.zclient.ZClientException.IO_ERROR(ZClientException.java:47)
        at com.zimbra.cs.zclient.ZMailbox.invoke(ZMailbox.java:524)
        at com.zimbra.cs.zclient.ZMailbox.invoke(ZMailbox.java:514)
        at com.zimbra.cs.zclient.ZMailbox.addMessage(ZMailbox.java:1822)
        at com.zimbra.cs.service.mail.ItemActionHelper.executeRemote(ItemActionHelper.java:504)
        at com.zimbra.cs.service.mail.ItemActionHelper.schedule(ItemActionHelper.java:320)
        at com.zimbra.cs.service.mail.ItemActionHelper.MOVE(ItemActionHelper.java:105)
        at com.zimbra.cs.service.mail.ItemAction.handleCommon(ItemAction.java:124)
        at com.zimbra.cs.service.mail.MsgAction.handle(MsgAction.java:43)
        at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEngine.java:410)
        at com.zimbra.soap.DocumentHandler.proxyRequest(DocumentHandler.java:419)
        at com.zimbra.soap.DocumentHandler.proxyRequest(DocumentHandler.java:403)
        at com.zimbra.cs.service.mail.ItemAction.proxyRemoteItems(ItemAction.java:187)
        at com.zimbra.cs.service.mail.ItemAction.handleCommon(ItemAction.java:100)
        at com.zimbra.cs.service.mail.MsgAction.handle(MsgAction.java:43)
        at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEngine.java:410)
        at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:267)
        at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:159)
        at com.zimbra.soap.SoapServlet.doPost(SoapServlet.java:266)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
        at com.zimbra.cs.servlet.ZimbraServlet.service(ZimbraServlet.java:188)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
        at org.mortbay.servlet.UserAgentFilter.doFilter(UserAgentFilter.java:81)
        at org.mortbay.servlet.GzipFilter.doFilter(GzipFilter.java:132)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
        at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:716)
        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:406)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
        at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
        at org.mortbay.jetty.handler.rewrite.RewriteHandler.handle(RewriteHandler.java:350)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
        at org.mortbay.jetty.Server.handle(Server.java:313)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
        at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:844)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
        at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: java.net.SocketTimeoutException: Read timed out
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
        at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:782)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:739)
        at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
        at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)
        at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
        at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1115)
        at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1832)
        at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1590)
        at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:995)
        at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
        at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
        at com.zimbra.common.soap.SoapHttpTransport.invoke(SoapHttpTransport.java:234)
        at com.zimbra.common.soap.SoapTransport.invoke(SoapTransport.java:297)
        at com.zimbra.cs.zclient.ZMailbox.invoke(ZMailbox.java:520)
        ... 43 more

[gantscha]

If i move a large message > 50MB to a shared folder or from a shared folder it fails and creates the mail multiple times in the destination folder!

I think that FileUploadServlet failes or gets a timeout and then the whole process is started again!

This seems to me like a serious bug.

It happens with the WebGui but also with Thunderbird.

[gantscha]

I can not understand why the FileUploadServlet is used if i move a message on the server?!? I don't know the internals of zimbra but to move a message wich is already on the server to a another "folder" on the server should be easy enough and not bothered with uploads and timeouts!

Whats going on?!?

I think this FileUploadServlet is also the guilty one why my Notebook is so slow. I covered this in an other thread.

[uxbod]

su - zimbra
zmprov gcf zimbraFileUploadMaxSize

[gantscha]

I did set the zimbraFileUploadMaxSize to 131072000.

This is not the problem!

Thanks anyway!

[phoenix]

@gantscha

Please don't add messages to other threads when you already have this one open, it makes it difficult to follow the answers to your posts and help you fix the problems.

[gantscha]

If you mean the "Notebook very slow" thread than i have to say that i first thought those where two different problems!

If you mean any other threat or that i should only have one active thread at all than i don't really agree but will follow and respect your guidelines and rules.

Please don't get me wrong - I would love to use zimbra in our company. The idea of having only a great webclient is just what i want but if it cant handle large attachments then this should be fixed or stated clearly because its a major point for companies like ours making/preventing the move to zimbra.

Would be great to get some information what is going on and if this is only a problem with my server/setup/settings or a limitation of zimbra.

Thank you.

[phoenix]

No, I meant this thread: QUESTION: Sending large attachments - that was for the Hosted Demo and not a local install. Zimbra can handle large files, many users can upload/download/delete large files without problem.