SWA MESS

[hmb]

Hello,
we have installed Scalix since end of Sept. 08.
We have never seen a full functional SWA. The search-function is NOT working. We have also a support ticket but the support in germany is by far not fast enough. We are waiting for a solution now for more than a week (since 30 of sept).
The technical info:
The http api-interface is not working well, the search-function does not deliver results. The error 500 occurs.
SWA delivers the following result (Apache-Access log)
------------------------------------------
112.3.90.3 - - [07/Oct/2008:18:09:02 +0200] "POST /sis/searcher?uid=01310000da41c384-3.09.3.211&q=%28from%3a%22hallo%22%20OR%20subject%3a%22hallo%22%20OR%20BODY%3a%22hallo%22%20OR%20to%3a%22hallo%22%29%20AND%20%28MSG-TYPE%3aemail%29&start=0&end=99&raw=true&stats=true HTTP/1.1" 200 4322 "-" "-"
112.3.90.3 - - [07/Oct/2008:18:09:02 +0200] "GET /api/xxx@yyy.de/search/?q=(from:%22hallo%22%20OR%20subject:%22hallo%22%20OR%20BODY:%22hallo%22%20OR%20to:%22hallo%22)%20AND%20(MSG-TYPE:email)&i0=INBOX&start=1&end=100&preview=true HTTP/1.1" 500 3232 "-" "Scalix Web Access"
------------------------------------------

The sxsearch is working and delivering results.
sxmkindex -r 0 "User Name" is ok.
The server has been rebooted to exclude that the problem is only temporary
The error must be somewhere between Apache and Scalix

Every SWA-Users search-function delivers NO results.
=========================================
Its very sad that we have to pay for support but there is no help coming.
Anyway, maybe that someone can help from here

[schmoe90]

Assuming that everything else is in line, check /etc/sysconfig/i18n:

Code: Select all

...
LANG="en_US.UTF-8"
...


[hmb]

This is already known.
This is not the solution!

[hmb]

Seems that there is nobody?

As far as I can see:
SWA- does not work, not only that the search function is not working, there are several features the web-client does not have (drag`n drop, append several files in one step., unload several appendices from received mails in one step, no connection-helper for windows to start email out of an other application or via right click- send to ...). All our users say that SWA is a step back. Also, sometimes things dont work and we have to reset the cache of that specific user (e.g. setting an appointment)

Now the support is also a mess, even that we have a ticket there is no action anyway.
Conclusion:
Scalix with SWA is not feature rich enough to be used in productive environment. Using M$ -Outlook is not an option and thunderbird´s calender function does not really support the Scalix features.
Finally we have to look out to find another solution and stop paying any bills to Scalix.
So, if nothing will happen, this week is the finall week of Scaliy in our company!!!

((

[schmoe90]

If you have a support ticket open, you should proceed with that, as that's the main job of support engineers. This is a free support area, where the community comes together to try and help each other out.

[hmb]

That is correct.
But this is an issue of neither nor!

[florian]

1. Can you post the output of

Code: Select all

strings /proc/`pgrep java`/environ

2. Can you post the output of

Code: Select all

ifconfig

and of

Code: Select all

cat /var/opt/scalix/??/sis/sis.properties

?

3. Did you modify anything in the Apache config manually either before or after installing Scalix or is this the OS's Vanilla Apache config.

I have checked our support records. You sent your request to our presales alias before you actually purchased Scalix afaics. Unfortunately, we do not currently have a tight SLA in our presales queue. I agree however, that even without an SLA, your ticket remained unattended for too long and we'll see what we can do to improve processing for presales requests.

In the meantime, we've moved this over to the support queue, which has a SLA (depending on the priority and severity and the entitlement). In the future, please open new support requests using the reporting form at http://www.scalix.com/support and those should be taken care of quicker.

I'm also disappointed to hear that you don't believe SWA is useable in a day-to-day production environment; I actually use it myself quite often and find it pretty useable and we have customers relying on it with thousands of users. I appreciate your feedback and points are noted, some of which will be addressed in a future release. Search must be a configuration issue as it does work on freshly installed QA systems as well as on our internal production systems.

Can you explain where you're missing drag & drop in SWA as there are quite a number of actions where this can be used.

Again, I hope we can resolve those issues to your full satisfaction,
Florian

[Markus23]

Hi there..

i'd like to add my 2 cents to this thread, because i'm kind of involved in this too (sysadmin at HMB's company).

Florian , you are right the ticket was started in the presales queue because we were waiting for our license to arrive to be able to open tickets in the normal support queue.
But i phoned german sales (Mr. S.) last thursday and he assured me that he changed the ticket to the normal support queue to speed up the whole process.
Since then I got NO reply from ticket system till this morning (half thursday, friday, monday means 2 and half day NO reaction!).
Today I finally got a reply asking me for a remote session to our machine. Let's see how long it will take to negotiate this remote session via email (Telephone anyone ?!).

But enough of this, here are some of the infos you like to know.

Strings output:

Code: Select all

SSH_AGENT_PID=2680
HOSTNAME=localhost.localdomain
DESKTOP_STARTUP_ID=
TERM=xterm
SHELL=/bin/bash
CATALINA_HOME=/opt/scalix-tomcat
HISTSIZE=1000
GTK_RC_FILES=/etc/gtk/gtkrc:/home/mk/.gtkrc-1.2-gnome2
WINDOWID=37751810
CATALINA_BASE=/var/opt/scalix/sx/tomcat
http_proxy=http://10.0.0.250:80
USER=mk
LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:
GNOME_KEYRING_SOCKET=/tmp/keyring-jUHTPz/socket
SSH_AUTH_SOCK=/tmp/ssh-EboWJT2645/agent.2645
SESSION_MANAGER=local/scalix.brueckmann-gmbh.de:/tmp/.ICE-unix/2645
USERNAME=mk
MAIL=/var/spool/mail/mk
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/opt/scalix/bin
DESKTOP_SESSION=default
GDM_XSERVER_LOCATION=local
INPUTRC=/etc/inputrc
PWD=/home/mk
XMODIFIERS=@im=none
LANG=de_DE.UTF-8
GDMSESSION=default
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
SHLVL=5
HOME=/root
GNOME_DESKTOP_SESSION_ID=Default
CATALINA_PID=/var/opt/scalix/sx/tomcat/tomcat.pid
LOGNAME=mk
CVS_RSH=ssh
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-DD2c04JyeH,guid=997deb4898b524660a1de25e14950d00
OMCURRENT=scalix
LESSOPEN=|/usr/bin/lesspipe.sh %s
G_BROKEN_FILENAMES=1
COLORTERM=gnome-terminal
XAUTHORITY=/root/.xauthoNS4ha
_=/usr/java/jre1.5.0_13/bin/java
LD_LIBRARY_PATH=/usr/java/jre1.5.0_13/lib/i386/server:/usr/java/jre1.5.0_13/lib/i386:/usr/java/jre1.5.0_13/../lib/i386


ifconfig output:

Code: Select all

bond0     Link encap:Ethernet  Hardware Adresse 00:1C:23:B8:87:B3
          inet Adresse:10.0.0.3  Bcast:10.0.255.255  Maske:255.255.0.0
          inet6 Adresse: fe80::21c:23ff:feb8:87b3/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:227528778 errors:0 dropped:0 overruns:0 frame:0
          TX packets:275480336 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:1916553977 (1.7 GiB)  TX bytes:186554137 (177.9 MiB)

eth0      Link encap:Ethernet  Hardware Adresse 00:1C:23:B8:87:B3
          inet6 Adresse: fe80::21c:23ff:feb8:87b3/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:1625073 errors:0 dropped:0 overruns:0 frame:0
          TX packets:135914766 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:470313000 (448.5 MiB)  TX bytes:3620605879 (3.3 GiB)
          Interrupt:169 Speicher:f8000000-f8012100

eth1      Link encap:Ethernet  Hardware Adresse 00:1C:23:B8:87:B3
          inet6 Adresse: fe80::21c:23ff:feb8:87b3/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:225903705 errors:0 dropped:0 overruns:0 frame:0
          TX packets:139565570 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:1446240977 (1.3 GiB)  TX bytes:860915554 (821.0 MiB)
          Interrupt:169 Speicher:f4000000-f4012100

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:21263304 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21263304 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:1309626163 (1.2 GiB)  TX bytes:1309626163 (1.2 GiB)


sis.properties

Code: Select all

# Scalix Search and Index Service properties

# run the index with extended summary data (debug/fun only) (requires index rebuild)
index.index.summary=false

# max size of the index processing queue
index.max.queue.size=10000

# max milliseconds to wait before processing
index.max.queue.age=15000

# max numbers of message documents to cache in memory
index.doc.cache.size=500

# Lucene merge factor - the number of segments on disk to allow before merging
# them into a larger segment.  Larger numbers will result in fewer mergers and
# larger segments which will in turn improve search performance, but this will
# generally be at the cost of increased I/O during indexing (and indexing is
# more common than searching).
# see http://lucene.apache.org/java/docs/api/org/apache/lucene/index/IndexWriter.html#DEFAULT_MERGE_FACTOR
# default: 10
#index.lucene.mergefactor=10

# Lucene max buffer docs - the number of documents to keep in memory before
# a new segment is created on disk (changing this is not generally useful).
# http://lucene.apache.org/java/docs/api/org/apache/lucene/index/IndexWriter.html#DEFAULT_MAX_BUFFERED_DOCS
# default: 10
#index.lucene.maxbuffereddocs=10

# content analyzer class (requires index rebuild)
index.content.analyzer.class=com.scalix.index.message.MessageAnalyzer

# MIME message parser class (requires index rebuild)
index.mime.indexer.class=com.scalix.index.message.IndexableMimeMessage

# language to use for indexing, analysis, stemming and searching all
# messages (requires index rebuild)
# default: English
index.language=German

# lock down requests from given IP addresses only
# default: empty
index.client.whitelist=10.0.0.3,127.0.0.1

# default maximum number of results to return; clients generally
# specify the maximum number of search results.
search.max.results=200

# lock down requests from given IP addresses only
# default: empty
search.client.whitelist=10.0.0.3,127.0.0.1

# Allow/Restrict search strings to begin with an asterisk (e.g. *ootball)
# which can drive up load if used a lot.
# default: true (restrict with flase)
search.client.leading_asterisk_permitted=true

# lock down requests to /admin/* from given IP addresses only.
# This includes http://<host>/sis which gets mapped to /sis/admin
# /admin/* is reserved for internal use by SCALIX support staff.
# default: empty
indexadmin.client.whitelist=10.0.0.3,127.0.0.1


So maybe this information leads to any solution for our main problem , the search function ?!


The Problem isn't the search function at all, because using sxsearch via terminal I receive results. It seems the problem exists between search function and apache , remember this 500 Error in apache log ?
But the apache config is centOS vanilla, no additions made from us. Clean centos install, standard scalix install.


Bye,

Markus

[florian]

looking at the output of the command containing the line

Code: Select all

LANG=de_DE.UTF-8


and given request by schmoe90 - actually a Scalix employee doing this in his spare time -

Assuming that everything else is in line, check /etc/sysconfig/i18n:

Code: Select all

...
LANG="en_US.UTF-8"
...


I don't know how to read

This is already known.
This is not the solution!

Can you please check that setting again? We have seen issues where the LANG was set to something other than en_US for the server setting; this unfortunately depends on the OS distro and packages installed, so we'd like to play it safe here.

I have internally followed up with support management and "Mr. S" to investigate into why this ticket has had a late response, but I will assume that the support team will now take care of the issue.

Thx,
Florian.

[dirk]

The main issues in this case has been identified a problem related to the LANG variable.
Especially when using CentOS make sure that /etc/sysconfig/i18n is defined as already mentioned in this thread.

Please note that a reboot may be the easiest way to ensure that all related components have read the new setting.

Scalix Support has opened a bug for this issue https://bugzilla.scalix.com/show_bug.cgi?id=18405. Development is currently investigating if it is possible to make the Search and Index Service more independent from the language settings of the Operating System.