Share Point Protocol Support in Alfresco 3.4 – Continued

In my last post I talked about how we configured the SPP (Share Point Protocol) support in Alfresco 3.4, including how to add SSL (https).

We have since also load balanced the SPP ports. But the journey is not as smooth as expected. I will share what we have learned in the process.

It looks very trivial. If you have a decent load balancer, you can just load balance https://dmsp.yourco.com (SPP) and https://dm.yourco.com to http://dm1.yourco.com and http://dm2.yourco.com. Apache on the dmx servers knows how to direct the traffic to either the AJP port for regular alfresco traffic or to the Jetty port for Share Point Protocol traffic.

Indeed, it did work, but only half way.  Clicking Edit Online option for a MS Word file in Alfresco Share in IE,  MS Word is launched and opened the file prompting to enter user name and password again. It’s understandable, as behind the scene, MS Word builds a WebDAV connection to the embedded Jetty server within the Alfresco DM server. Now I am  happy and edit away. Being cautious, I save the changes that I have just happily made.  The progress bar shows that the changes are saved remotely to the server. Now I  go back to the IE window and refresh the file preview page again, I notice that my hard work does not get saved, even though the time stamp has changed.

So we turned the SPP debug on and also watched the Apache access log and error log files. We separated the log files for dmsp.yourco.com and dm.yourco.com. The logs did not show anything unusual.

alfresco.log

16:56:25,581 DEBUG [org.alfresco.module.vti.web.VtiFilter] Checking request for VTI
16:56:25,581 DEBUG [org.alfresco.module.vti.web.VtiFilter] Check authentication16:56:25,586 DEBUG [org.alfresco.module.vti.handler] Resolved file info for 'xxxxx/_vti_bin/_vti_aut/author.dll' is null
16:56:25,588 DEBUG [org.alfresco.module.vti.handler] Resolved file info for 'xxxxx/_vti_bin/_vti_aut' is null
16:56:25,590 DEBUG [org.alfresco.module.vti.handler] Resolved file info for 'xxxx/_vti_bin' is null
16:56:25,592 DEBUG [org.alfresco.module.vti.handler] Resolved file info for 'xxxx' is FileInfo[name=xxxx, isFolder=true, nodeRef=workspace://SpacesStore/86c1e943-5ea7-4afc-8bea-b7c44eb81455]
16:56:25,593 DEBUG [org.alfresco.module.vti.handler.alfresco.v3.AlfrescoMethodHandler] WebUrl: /alfresco/xxxxxx, fileUrl: '_vti_bin/_vti_aut/author.dll'

Apache access.log:

 [12/Apr/2011:16:56:16 -0400] "OPTIONS /alfresco/xxxx/documentLibrary/ HTTP/1.1" 401 - "-" "Microsoft Office Protocol Discovery"
[12/Apr/2011:16:56:24 -0400] "OPTIONS /alfresco/xxxx/documentLibrary/ HTTP/1.1" 200 - "-" "Microsoft Office Protocol Discovery"
[12/Apr/2011:16:56:24 -0400] "GET /_vti_inf.html HTTP/1.1" 200 246 "-" "Mozilla/4.0 (compatible; MS FrontPage 14.0)"
[12/Apr/2011:16:56:24 -0400] "POST /_vti_bin/shtml.dll/_vti_rpc HTTP/1.1" 200 230 "-" "MSFrontPage/14.0"
[12/Apr/2011:16:56:24 -0400] "POST /_vti_bin/shtml.dll/_vti_rpc HTTP/1.1" 200 193 "-" "MSFrontPage/14.0"
[12/Apr/2011:16:56:25 -0400] "POST /alfresco/xxxxx/_vti_bin/_vti_aut/author.dll HTTP/1.1" 401 - "-" "MSFrontPage/14.0"

It all looks fine, but the file did not get saved, no matter how hard MS Word tried.

Here comes the rescue of tcpdump, by looking deeply into the packets, here is what we found:

HTTP Request:

LOCK /alfresco/alfadmin/documentLibrary/***.doc HTTP/1.1

HTTP Response:

HTTP/1.0 501 Not Supported

We called upon our firewall and networking folks again. But this does not appear to be a firewall issue, as firewall usually does not inspect layer 4 protocol such as http. Our networking group found the following:

HTTP lock method does not always get to the client.

Symptom:
HTTP lock method does not always get to the client.
501 http error sent from switch.

Cause:
Lock/Unlock http method is not supported in Nortel Application Switch Operating System (formerly known as AlteonOS) 21.0

Fix:
Lock and unlock http method are not supported on 21.0.4.5 code. The reason why some worked and some did not was because on packet streams where the Switch VIP sees a supported method (GET etc…) the switch will allow the following Lock and Unlock. On the streams where the lock is the first http method seen by the VIP a 501 error is sent back to the client.
An additional feature to support additional HTTP methods has been introduced in 22.0.
You will have to add the lock and unlock methods using the following command after you have your old configuration on the switch.
/cfg/slb/layer7/slb/addmet LOCK
/cfg/slb/layer7/slb/addmet UNLOCK

There we have it, the problem is in the load balancer and as soon as the LOCK and UNLOCK methods were added to the load balancer, it’s working like a charm.

So when load balancing any applications, watch for the fine prints, especially hardware load balancer.

Advertisements
This entry was posted in JAVA, OPEN SOURCE and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s