every ZxSuite Zimlet install fails -- once. 2nd attempt always works.

[rbsf]

moved thread, previously @
http://forums.zextras.com/zextras-cu...ays-works.html

every ZxSuite Zimlet install fails -- once. 2nd attempt always works.

just fyi,

each/every time the ZeXtras Suite Zimlet is installed, it FAILs. Once.

an immediate re-install is ALWAYS successfuly.

from the install session:

...
[] ERROR: Error
com.zimbra.common.service.ServiceException: system failure: Unable to deploy Zimlet com_zextras_zextras.zip on zimbra.mydomain.com
ExceptionId:main:1367604090688:7b7b7e73ddbd2e8a
Code:service.FAILURE
at com.zimbra.common.service.ServiceException.FAILURE (ServiceException.java:258)
at com.zimbra.cs.zimlet.ZimletUtil$ZimletSoapUtil.dep loyZimletOnServer(ZimletUtil.java:1497)
at com.zimbra.cs.zimlet.ZimletUtil$ZimletSoapUtil.dep loyZimlet(ZimletUtil.java:1408)
at com.zimbra.cs.zimlet.ZimletUtil.deployZimletBySoap (ZimletUtil.java:1184)
at com.zimbra.cs.zimlet.ZimletUtil.dispatch(ZimletUti l.java:1808)
at com.zimbra.cs.zimlet.ZimletUtil.main(ZimletUtil.ja va:1907)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream. java:150)
at java.net.SocketInputStream.read(SocketInputStream. java:121)
at sun.security.ssl.InputRecord.readFully(InputRecord .java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java :480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocke tImpl.java:927)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLS ocketImpl.java:884)
at sun.security.ssl.AppInputStream.read(AppInputStrea m.java:102)
at java.io.BufferedInputStream.fill(BufferedInputStre am.java:235)
at java.io.BufferedInputStream.read(BufferedInputStre am.java:254)
at org.apache.commons.httpclient.HttpParser.readRawLi ne(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine( HttpParser.java:106)
at org.apache.commons.httpclient.HttpConnection.readL ine(HttpConnection.java:1116)
at org.apache.commons.httpclient.HttpMethodBase.readS tatusLine(HttpMethodBase.java:1973)
at org.apache.commons.httpclient.HttpMethodBase.readR esponse(HttpMethodBase.java:1735)
at org.apache.commons.httpclient.HttpMethodBase.execu te(HttpMethodBase.java:1098)
at org.apache.commons.httpclient.HttpMethodDirector.e xecuteWithRetry(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.e xecuteMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMe thod(HttpClient.java:397)
at com.zimbra.common.httpclient.HttpClientUtil.execut eMethod(HttpClientUtil.java:42)
at com.zimbra.common.httpclient.HttpClientUtil.execut eMethod(HttpClientUtil.java:28)
at com.zimbra.cs.zimlet.ZimletUtil$ZimletSoapUtil.pos tAttachment(ZimletUtil.java:1608)
at com.zimbra.cs.zimlet.ZimletUtil$ZimletSoapUtil.dep loyZimletOnServer(ZimletUtil.java:1480)
... 4 more

Zimlet installation failed. Exiting.
.......
The zimlet installation has failed. That might be due to an incomplete startup
of the Zimbra webapp. Please verify Zimbra is up and running, then retry
the deployment of the zimlet with ./install.sh zimlet .
.......

originally @ 03-15-2013, 03:33 PM,

zextras 1.8.3, installing on zimbra 8.0.2 -> FAILs, as reported above.
zextras 1.8.4, installing on zimbra 8.0.3 -> FAILs, as reported above.
zextras 1.8.5, installing on zimbra 8.0.3 -> FAILs, as reported above.
...
zextras 1.8.8, installing on zimbra 8.0.4 -> FAILs, as reported above.

changing 'sleep 60' -> 'sleep 240' in install.sh has no effect
immediate 2nd exec of 'install.sh zimlet' *always* works ...

[Cine]

Hello rbsf!

Just some quick info in order to inform the community about this situation (since quite some posts were made in the original thread):

As you all know, during the ZeXtras Suite/ZxMig installation process the mailboxd service is stopped in order to install the ZeXtras Core and then restarted to install the ZeXtras Administration Zimlet - the install script uses the standard `zmzimletctl deploy` command, which requires the mailboxd service to be running.
Due to the poor reliability of the service status information during a service start a 60-seconds hardcoded delay has been included to the ZeXtras Installer in order to let the mailboxd service completely start. This value is appropriate in most cases, while sometimes the mailboxd service takes longer to start and the ZeXtras Administration Zimlet installation will fail due to the service not being 100% started.

After noticing the constant fail of the ZeXtras Administration Zimlet's install process, rbsf tried to tweak the hard-coded delay to an higher value, but the installer kept failing with the same error.

The error reported (java.net.SocketTimeoutException: Read timed out) is strictly related to the mailbox service being unavailable, and we haven't been able to reproduce the issue on our test environments, so if somebody experiences the same issue please post in this thread.
In order to test a different delay, search for the following fragment in the install.sh file

 echo "Waiting 60s for Zimbra to initialize ..."
  sleep 60
  isZimbraActive


  if [ $? -eq 0 ]; then
    ZIMBRA_STATUS=1
  else
    echo "The Zimbra Web Application failed to start. Exiting ..."
    exit 1
  fi

and change the sleep value to a higher number.


Have a nice day,
Cine

[rbsf]

> change the sleep value to a higher number

Values as high as =240 still don't work, here.

For those interested, there _appear_ to be no adverse effects/behaviors/problems/etc after the "2nd install" of the zimlet. Unclear to me how to verify that that's really the case, given the errors the first time around.

When asked whether to use in production, although I do for my own server, my answer to deployment clients is simply "caveat emptor" at this point.

[Cine]

Hello rbsf!

As previously stated, the "java.net.SocketTimeoutException: Read timed out" you experience during the installation process of the ZeXtras Administration Zimlet is strictly related to the mailbox service being momentarily unavailable.
Unfortunately this, plus the fact that the command used for the zimlet installation is the standard `zmzimletctl deploy` - a Zimbra CLI command that only interacts with the LDAP and the mailboxd components and not with the zimlet itself - allows us for a very limited range of action. Adding a delay to the installer in order to lower the chances of the mailboxd being unavailable is as far as we can go, as we can't tamper in any way with how `zmzimletctl` works and this is the only officially supported way to deploy a zimlet... "Ubi maior, minor cessat"
On the bright side, for the very same reasons it's very unlikely for the zimlet installation issues to affect the functionality of the product, unless there is an underlying cause that affects the mailboxd service in general.

In order to further analyze the cause, please send me the following data - I'll be more than glad to check the situation with our developers:

- ouput of a clean ZeXtras Suite install ran with the "-d" option (debug mode - please run "date && ./install.sh -d all" from within the ZeXtras Suite package folder in order to better cross-check this output with the mailbox.log).
- the complete mailbox.log file for the day.

Please send the logs to community@zextras.com.

Have a nice day,
Cine
the ZeXtras Team