mobile calender Internal Server Error

[padraig]

i'm getting:

Internal Server Error
The server has encountered an internal error.

when i login to the mobile calender on one of my 5.04 (upgraded from 4.56) boxes, the second one works ok, any suggestions?

TIA,
p.

[padraig]

its caused by a missing:
/opt/zimbra/jetty/work/zimbra/jsp/org/apache/jsp/tag/web/mobile/moAttachments_tag.class

beware of removing /opt/zimbra/jetty/work/* to solve the ssh

system failure: exception during auth {RemoteManager: zimbra.snp.org->zimbra@zimbra.snp.org:22}

[LMStone]

Originally Posted by padraig

its caused by a missing:
/opt/zimbra/jetty/work/zimbra/jsp/org/apache/jsp/tag/web/mobile/moAttachments_tag.class

beware of removing /opt/zimbra/jetty/work/* to solve the ssh

system failure: exception during auth {RemoteManager: zimbra.snp.org->zimbra@zimbra.snp.org:22}

Well, if you search the forums for "Internal Server Error" you'll see that doing an rm -rf /opt/zimbra/jetty/work/* is a recommended step in the fix.

We are having this internal server error problem now with html clients after cleaning out the jetty work directory for another (java memory consumption) issue.

I see in the logs the system complains about a missing dislayMessage_tag.class file

How can this file be restored?

Thanks,
Mark

[uxbod]

Mark, if you have a backup the file is here

[zimbra@office tmp]$ find /opt/zimbra -name displayMessage_tag.class 2>/dev/null
/opt/zimbra/jetty-6.1.5/work/zimbra/jsp/org/apache/jsp/tag/web/message/displayMessage_tag.class

as long as you are on 5.0.4 as between releases could be a different jetty version!

[jholder]

Guys-
JSP is a compiled at runtime programming language. This is different than PHP. PHP compiles on the fly, then sends back the compiled version to the browser.

JSP compiles pages, stores them in the work directory as a cache incase another user calls it.

If a file is missing from the work dir, it means that the jsp page isn't compiling correctly.

So, the problem isn't really that the file is missing...it's missing because it's not getting compiled.

Did you restart mailboxd? We had this issue back in 5.0.2

[jholder]

re:

beware of removing /opt/zimbra/jetty/work/* to solve the ssh

He's right in a sense. Removing the work dir wouldn't solve the ssh key mgmt issue..It doesn't hurt anything. If anything in the work dir is missing, the server will recompile it.

[uxbod]

Originally Posted by jholder

If a file is missing from the work dir, it means that the jsp page isn't compiling correctly.

John, when a error message pops up in the logfiles for things like this, how can we help to debug it ?

[jholder]

Originally Posted by uxbod

John, when a error message pops up in the logfiles for things like this, how can we help to debug it ?

That's the tricky part

Stop mailbox
clear work dir
turn up debugging (sever ajax problems)
start mailbox

Look for the exception before the fnf error. It should give a compiling error. Let's see why it can't compile

[LMStone]

Originally Posted by uxbod

Mark, if you have a backup the file is here

[zimbra@office tmp]$ find /opt/zimbra -name displayMessage_tag.class 2>/dev/null
/opt/zimbra/jetty-6.1.5/work/zimbra/jsp/org/apache/jsp/tag/web/message/displayMessage_tag.class

as long as you are on 5.0.4 as between releases could be a different jetty version!

Thanks Uxbod. I restored the missing class file from a backup, restarted the mailbox and now it works.

Mark

P.S. You may want to change:

[zimbra@office tmp]$ find /opt/zimbra -name displayMessage_tag.class 2>/dev/null

to

[zimbra@office tmp]$ find /opt/zimbra/jetty -name displayMessage_tag.class 2>/dev/null

to avoid searching the store and database directories, which on a production might take a while... :-)

[jholder]

Originally Posted by LMStone

Thanks Uxbod. I restored the missing class file from a backup, restarted the mailbox and now it works.

Mark

P.S. You may want to change:

[zimbra@office tmp]$ find /opt/zimbra -name displayMessage_tag.class 2>/dev/null

to

[zimbra@office tmp]$ find /opt/zimbra/jetty -name displayMessage_tag.class 2>/dev/null

to avoid searching the store and database directories, which on a production might take a while... :-)

BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD BAD

You're addressing the symptom and not the problem. It's only a matter of time before the cache is cleared, and the compiling fails again
BAD BAD BAD BAD