Posts Tagged ‘Collaboration’
Tuesday, June 7th, 2011
WebCenter Collaboration Server has a decent feature that allows end users to email documents directly to Collaboration Server by using a dedicated SMTP address for each folder:
Properly configured, attachments (but not message text) on any email coming in to that address are created as documents in the Collab Folder. But what if you want to capture the text of that email? And what if the user doesn’t have an account in Collab? Also, wouldn’t it be nice if inbound documents to the few folders you care about allowing (possibly anonymous) document submissions could have “vanity email addresses” like rrrgm8ty@mycompany.com for the pirates in your organization?
That’s exactly what SMTP2Collab does. Like Collab, it sets up an inbound SMTP server. Any mail delivered to it – whether the user has an account in the portal or not – gets created as a document in the specified folder, and a linked discussion is also created containing the text of the email. Oh, and you can create any vanity aliases you want for the folders:
Wanna see it in action? You know the drill.
Tags: appforthat, Collaboration, smtp
Posted in App For That, Collaboration Server | Comments Off
Tuesday, May 10th, 2011
Today’s post comes from a Rock Star Consultant in the WebCenter Consulting space. It has to do with WCI Collaboration Server consuming 100% CPU on Solaris, but might be relevant to those Windows users out there. While I personally haven’t experienced this particular issue at client sites (virtually all of them Windows), it sounds like if you’re running Collab in Unix, it might be worth upgrading your JVM.
Problem:
Collab periodically starts chewing up CPU until it maxes out the box and ultimately dies.
Details:
This looks to ultimately be a problem at the JDK level. Out of the box, the Tomcat Collab is deployed to uses JDK 1.5. There’s a bug in JDK 1.5 that causes the NIO connector in tomcat to sometimes freak out, resulting in Collab spinning out of control and eating all the server CPU. For details, see this thread:
http://www.mail-archive.com/users@tomcat.apache.org/msg36900.html
Diagnosis:
Here’s the rundown on the diagnosis we did (Collab on Solaris)
Symptom:
Collab is eating up a huge amount of CPU minimal user load(80%+ on a server where it usually uses ~10%).
Troubleshooting performed:
1) Generated a stack trace for Collab
2) Run prstat -Lp <Collab Pid>. This shows us how much CPU each thread in Collab is taking. Note that the top three threads in the attachment are taking up 22% of the CPU each. Also note that those threads have used a huge amount of CPU time: 3-4 hours each).
3) Note the LWPID of each of the busy threads: 6248, 3413, 8198.
4) Now convert those numbers to Hex:
6248 -> 1868
3413 -> d55
8198 -> 2006
5) Now look for those hex thread ids in the thread dump. You’ll see they all have the same stack (for example: nid=0xd55). Specifically:
—————————
“http-7127-exec-23″ daemon prio=10 tid=0x00000001008ee360
nid=0xd55 runnable [0xfffffffeff0fa000..0xfffffffeff0ff728]
at org.apache.coyote.http11. InternalNioOutputBuffer.addToBB(InternalNioOutputBuffer.java:610)
- waiting to lock <0xffffffff40927c48> (a org.apache.coyote.http11.InternalNioOutputBuffer)
at org.apache.coyote.http11. InternalNioOutputBuffer.access$000(InternalNioOutputBuffer.java:44)
at org.apache.coyote.http11. InternalNioOutputBuffer$SocketOutputBuffer.
doWrite(InternalNioOutputBuffer.java:794)
at org.apache.coyote.http11. filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:126)
SNIP
Again, note that all the stack traces are the same and they appear to be trying to flush/close and output stream, but it looks like they’re blocked.
Fix:
Update the Collab JVM to a recent release of the 1.6 JDK (1.6u23 for example). Restart Collab
Results:
Prior to change, Collab was crashing multiple times a day and using at least 20% of the CPU on a beefy Solaris box. Post change, no Collab crashes, and Collab is pretty consistently using about 4% of CPU on the server.
Tags: Collaboration, haker, java, JVM
Posted in Collaboration Server | Comments Off
Thursday, March 24th, 2011
If you, like me, were foolish enough to upgrade your Java Runtime Environment to 1.6.0_24 (I mean, REALLY, who DOES THAT!?), then you’ve likely found that Bulk Upload (and possibly WebEdit) no longer work in WCI Collaboration Server.
Why? This post by gimble2 about sums it up:
Java is under new management. Sun was very strict in keeping backwards compatibility; I wouldn’t be surprised if Oracle takes the policy of security first, compatibility second.
Indeed, this is a big problem because Java 1.6.0_24 lies to users:
Unrestricted Access, huh? Bullsh*t.
You can confirm this by viewing the Java Console when trying to run Bulk Upload:
There you’ll likely see an exception like this:
Java Plug-in 1.6.0_24
Using JRE version 1.6.0_24-b07 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\Administrator
Exception in thread “Basic L&F File Loading Thread” java.security.AccessControlException: access denied (java.io.FilePermission C:\Documents and Settings\Administrator\My Documents read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
(snip)
Exception occurred during event dispatching:
java.security.AccessControlException: access denied (java.io.FilePermission C:\Documents and Settings\Administrator\My Documents read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
(snip)
at com.plumtree.collaboration.app. bulkupload.BulkUploadApplet. chooseFiles(BulkUploadApplet.java:191)
at com.plumtree.collaboration.app. bulkupload.BulkUploadApplet. access$100(BulkUploadApplet.java:15)
at com.plumtree.collaboration.app. bulkupload.BulkUploadApplet$ 1FileChooserDisplayer.run (BulkUploadApplet.java:329)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1. doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
(more…)
Tags: Bug, Bulk Upload, Collaboration, java, WebEdit
Posted in Bug, Collaboration Server, Security | 1 Comment »
Friday, March 18th, 2011
We’ve now discussed why Office 2010 doesn’t work with Oracle WebCenter Collaboration Server, how it can be patched, and even the enigmatic post about Office 2010 document formats. So we know that Office 2010 WebDAV can work with Collab. But even though the Apache/AJP hack fixes WebEdit for Office 2010, unfortunately it breaks something else. Specifically, when you close a document that you’re “Web-Editing”, Office 2010 sends the file back to Collab, and it doesn’t seem to include a Content-Type header (damn headers…).
Because Collab isn’t told what the Content Type is, it has to guess, and as mentioned, the Office 2010 document format is a .zip file that contains XML. What ends up happening is that, after a successful WebEdit operation, if you try a simple download of that document in the portal, you get a .zip file with all those .xml docs in there. This threw me off for a bit, thinking that the original document was lost to this crazy .xml file. But, once I realized that renaming the file to .docx and opening in Word 2010 still worked, it was clear the problem was with the MIME type of the document, not the bits themselves.
This is good news – it means that Collab’s not really broken, but Office 2010 is sending the wrong Content Type when the document is closed (strangely, this happens when the doc is closed, not when it’s saved), and Collab is recording that Content Type to its CSFILES table in the database. Specifically, the ContentType field in the CSFILES gets set to text/xml; charset=”utf-8″:
The best fix (hack?) I’ve found here is to create a trigger on this table to cancel out any changes that set this content type to that value. In other words, the MS SQL trigger looks for the value of “text/xml; charset=”utf-8″” during and update, and if it’s there, the trigger rolls back the value to the original value. As usual, proceed at your own risk, and while I can’t foresee any problems – even when uploading XML files to Collab, which are likely to have a different Content Type – this is a high-risk DB update that Oracle definitely won’t support.
(more…)
Tags: Collaboration, database, hack, WebDAV, WebEdit
Posted in Collaboration Server, WebEdit | Comments Off
Wednesday, March 16th, 2011
Sit back and let me rap atchya, slinging some factasms about the Office 2010 document format (.docx, .xlsx, .pptx).
You’ve no doubt been using Office 2010 for a while and saving files with those new formats that don’t work in Office 2007. Those .docx, .xlsx, and .pptx files are part of the Office Open XML file format. What you may not know is that they’re actually ZIP files. Really – try taking any .docx file you’ve got and adding .zip to the end – it’s a .zip file:
Who knew, huh? More importantly, what’s this post doing on a Plumtree bog?
If you’re planning on using WebEdit with WCI Collaboration and Office 2010, it’s a very important nuance, because yesterday’s Collaboration WebEdit Hack isn’t going to be practical without this nugget of knowledge.
Tags: Collaboration, Office, WebEdit
Posted in Collaboration Server, Knowledge Directory | Comments Off
Tuesday, March 15th, 2011
As we saw a couple days ago, WebCenter Collaboration Server doesn’t work with Office 2010. The problem is rooted in the fact that WebDAV calls to Collab from Office 2010 aren’t strictly RFC-compliant because they’re missing a Content-Length header, and Tomcat rejects them because of that – even before Collab gets the HTTP requests.
Which got me to thinking: what if we could create an intermediate server that would add this header for us? Then Tomcat would accept the connection and we’d be able to tell if Collab was able to “do its thing”. I started down the path of creating an Apache ProxyPass to do just this, when a friend and fellow Hak’er (Brian Hak) – who has been fighting his own fires with Collab these days – suggested that I try AJP. Even better, he pointed out, Collab’s default configuration settings allow you to turn this on by just flipping a switch; with it, we could then use mod_headers to add the Content-Length header.
Tip o’ the the hat to Brian for the AJP idea – it turns out that if Apache and AJP are handling the HTTP requests rather than Tomcat and its embedded web server, we don’t even need to muck with HTTP headers, as the request does NOT get blocked:
… and WebEdit (mostly) works in Office 2010!
I should warn you before proceeding: While I can absolutely say that WebEdit works in my test environment with Office 2010, .NET WCI Portal 10.3.0, on IIS 6, your mileage may vary, and I can’t guarantee this will work. I’ve found that Office 2007 has its own quirks – it works with the Collab Office Tools plugin in the ribbon bar, but not the out-of-the-box “save” implementation using Office’s own WebDAV calls. Perhaps that’s a post for another day, but early results show that while this hack doesn’t hurt Office 2007 support, it doesn’t seem to help either. Obviously, do extensive testing before even considering moving to a production environment. Stay tuned for the next update in these pages, as there’s yet another database hack needed to make it fully functional.
 Disclaimers out of the way, let’s dig in. Basically, what we’re going to do is:
- Install Apache Web Server on the Collab Machine, with the AJP plugin
- Configure Collab to accept AJP calls
- Configure the portal to send requests to Apache instead of directly to Collab (Tomcat)
(more…)
Tags: Apache, Collaboration, hack, haker, Office, Tomcat, WebEdit
Posted in Bug, Collaboration Server, WebEdit | Comments Off
Tuesday, March 15th, 2011
I’ve blogged a LOT about Collaboration Server, and have spent countless hours fighting with the WebEdit features – it’s the “bane of my existence“, a term I used because I thought “crime against humanity” was a little too strong. More often than not I’ve thrown up my hands and said “sorry, fella, nothing to see here – it just plain don’t work”. The problem is there are a near-infinite number of combinations, between the different versions of:
- Plumtree / ALUI / WebCenter Interaction Portal (6.1, 6.5, 10.3.0, 10.3.0.1, 10.3/Neo)
- Collaboration Server (4.2, 4.5, 10.3.0, 10.3.0.1, 10.3/Neo)
- Windows (XP, Vista, 7), plus various patches
- Office (2003, 2007, 2010), plus various patches
- Application Servers (IIS, WebLogic, Tomcat)
- Web Browsers (IE7 and IE8 – good luck if you have IE9, FireFox or Chrome)
Officially, Oracle only supports the following for WebEdit with version 10.3.0.1 – the latest publicly available version: MS Office 2003 on Windows XP SP2; MS Office 2007 on Windows XP SP2. No Office 2010, no Windows 7. Even Office 2007 is patchy at best.
I’d heard enough complaints, and decided to dig in and try to figure out why one very specific combination doesn’t work: Office 2010 running on Windows 7 against an IIS 6 .NET portal running WebCenter Collaboration 10.3.0. Here’s what the out-of-the-box install shows when trying to save a file opened through WebDAV:
Your changes were saved but could not be uploaded because of an error. You may be able to upload this file using the server Web page.
Having not accepted that it was impossible to get WebDAV working in Office 2010, I’ve spent countless hours reverse-engineering Office’s WebDAV protocol, WebCenter Interaction gateway calls, Apache Tomcat protocol handling, and everything in between.
Based on my research, this hack may be helpful for other versions of Office, Windows, and Collab, but I can’t even guarantee the hack I’ll discuss in the next couple of days is perfect, even with these very specific versions. Proceed at your own risk, and drop me a line if you’d like to discuss your specific situation.
(more…)
Tags: Bug, Collaboration, hack, Tomcat, WebDAV, WebEdit
Posted in Bug, Collaboration Server, WebEdit | Comments Off
Sunday, March 13th, 2011
Last month, I posted a patch for the unsigned applets in WebCenter Collaboration Server. At the time, I said:
When your users click on the “More Information” link, you’ll see a message about Integryst asserting that the application is safe. That is true. But you’ll never hear me asserting that the application doesn’t suck.
That may have been a bit of an unfair jab – Plumtree Collaboration Server was a decent product in general, so let me refine the jab: as it evolved to ALUI Collaboration Server it remained a decent product that got the job done, even while showing its age as the years marched by. But WebDAV / WebEdit access in WebCenter Interaction is a complete mess – unless your end users are still using Windows XP and Office 2003. If they are, you’re in luck! The functionality merely “sucks”, which is much better than what I can say for your more modern users with Vista or Windows 7 using Office 2007 or Office 2010.
This tip is a simple and documented one: if all your users are on the corporate intranet and can directly access your Collab Server, you may get better results with WebEdit if you don’t gateway the requests through the portal. Just change “nonGatewayedAccess” to “yes” – and make sure your entire user base can access that URL (i.e., you’re not running an extranet where the Collab Server is behind a firewall).
<webEdit enabled="yes">
<nonGatewayedAccess enabled="yes">
<serverURL>http://collaboration_server:11930/collab</serverURL>
</nonGatewayedAccess>
<tokenBasedAuthentication enabled="true">
<useClustering enabled="no">
<maxWaitSeconds>30</maxWaitSeconds>
</useClustering>
</tokenBasedAuthentication>
<truncateFileNames>75</truncateFileNames>
<clientControl>
<clsid>6882A029-D576-45FC-B966-7288891BDF58</clsid>
<fileSpec>PTWebEditControl.CAB#version=1,0,0,0</fileSpec>
</clientControl>
<installOfficeToolsPopUp enabled="yes"/>
</webEdit>
Stay tuned for some even bigger news in a future post; with some extensive reverse-engineering of Microsoft Office’s WebDAV protocol implementation and Apache Tomcat’s HTTP implementation, I’ve gotten WebEdit and WebDAV working for Office 2010 on Windows 7. There are some side effects that I’m working through as we do some regression testing but I’m pretty confident we’ll have a solution ready soon for using Collab WebDAV with modern versions of Windows and Office. Drop us a line if you’d be interested in testing out the solution.
Tags: Collaboration, WebEdit
Posted in Collaboration Server, WebEdit | 2 Comments »
Thursday, March 10th, 2011
Oracle’s Upgrade Guide for WebCenter Interaction Collaboration Server include “Rebuild the Oracle WebCenter Collaboration search collection“.
A while back, I ran into an issue where the rebuild process was spiking the CPU on the Collab Server at 100% forever (which, I suppose, is more of a plateau than a spike). In viewing the PTSpy logs, I saw hundreds of thousands of messages that included this SQL statement:
select * from csIndexBulkDeletes where status = 1
Checking that table, I found over 110 MILLION rows. Which is particularly odd, given that this client only had 42,000 Collab Docs. Now, I have no idea how the table got that enormous, but it’s clear that Collab’s Search Rebuild process uses that table to determine which documents to update, much like the Search Update job uses the PTCARDSTATUS table – which, incidentally, can also get messed up.
It was clear that if the search rebuild process goes haywire, Collab starts queuing up search server updates in this table, and if the table gets too big, cascading failures start to occur where the queue grows faster than it can get purged.
The solution is: before starting the Collab Search Re-index process, clear this entire table, which is rebuilt during the re-index process anyway. To do so, just run:
truncate table csIndexBulkDeletes
I should note that this isn’t all that common, as I’ve only seen it once, but at least now you know one possible solution if your rebuild process can’t seem to gain escape velocity.
Tags: Collaboration, database, index, rebuild, search, Search Server
Posted in Collaboration Server, Search Server | Comments Off
Sunday, February 27th, 2011
Last month, we wrote to tell you about the WebCenter Interaction Collaboration Server IE8 Critical Fix. Last week, an old Plumtree pal dropped me a line to let me know that this patch has been updated (Thanks, Eno!). No new version information – it’s actually the exact same patch number and everything – although some of the code has changed a bit. As far as I can tell in analyzing the different packages, there are just a couple of tiny tweaks, and the release notes include a more comprehensive set of bug fixes, so you’ll just have to download the patch again to get the new binaries.
- WebEdit does not work on IE8. (9723488)
- Error in task submenu in IE8 (9712774)
- Cannot upload multiple files in Collab (9274372)
- Bulk upload JRE updated to 1.6 in order to support IE8 (8760280)
- Notifications should be sent from a fixed address for creation and deletion (9647426) This fix involves updates to both collab and notification components.
- Subscription to project overview causes conflicts with Immedate Subscriptions (8759642)
- Non gatewayed webedit does not work (9434805)
- File leak in Search Service during search index rebuild (11726008)
- Webcenter Collaboration notifications to large numbers of recipients fail (9484113)
Oh, and while I never got around to writing a post about this, for those of you that are into this kind of stuff, this update includes a new cns.war file – and someone in engineering has removed the .jars containing some of the CNS source code. So if you want to take a peek, check out the code in your cns.war before updating.
Guess you’ll have to find some other way to meet your code analysis needs…
Tags: Collaboration, Critical Fix
Posted in Collaboration Server, Oracle | Comments Off
|
