Posts Tagged ‘java’

Replace Collab’s horribly broken file uploader

Sunday, September 27th, 2015

While the entire WebCenter Interaction stack is now dead, there are still some of you out there using the legacy code because it “just works”.

As technology evolves, though, more and more pieces of the stack have started to crumble – including Collaboration Server’s multi-file upload. We’ve talked about issues with it in the past and hacked it more than once, but it pretty much just worked in IE7-9, and wasn’t even available in other browsers like Chrome.

So, enough was enough: in search of a better solution, I came across the awesome FineUploader product, which does an incredible job of allowing multiple uploads with virtually any browser (degrading properly based on available features of each browser), and doesn’t rely on any crap technology like Flash or Java.

Rather than completely re-inventing the wheel, I just cracked open the collab.war file and replaced the old crap code with new code leveraging; uploads themselves are still processed the exact same way that the old java app used to use, so nothing is compromised in terms of features or security. It was really only a few files that needed to be changed, which alters the upload form that used to look like this:
… to now look like this:

Cool Tools 18: HxD Hex Editor

Thursday, May 19th, 2011

Continuing our journey on increasing ALI Studio’s character limit, we’ve now identified the code that needs to change – it’s in com.plumtree. studio.model.

The problem is, Studio is ancient, so while we can easily update the following code:

  protected int mUserColumnWidth = 1000;
  protected int mUserColumnWidthChars = 1000;

… we can’t just recompile the file using the latest JDK without expecting problems.

So, we need to figure out what Java version was originally used to compile this file. To do this, we need today’s Cool Tool: HxD Hex Editor. Why? Because all Java .class files have the same set of bytes at the beginning identifying them as Java files, along with the JDK version used to compile.

HxD allows us to view the actual bytes, and and it does it well. Opening the TableDAO.class file in HxD, we see:

Bytes 6 and 7 are “00 2E”, which represent JDK 1.2.

Once we’ve made our changes and have the correct JDK downloaded, we rebuild the file, making sure to include the proper .jars in the CLASSPATH:

set CLASSPATH= %CLASSPATH%; C:\code\studio\ WEB-INF\lib\log4j-1.2.8.jar
set CLASSPATH= %CLASSPATH%; C:\code\studio\ WEB-INF\lib\jakartaRegexp1dot2.jar

C:\jdk1.2.2\bin\javac -classpath %CLASSPATH% com\plumtree\ studio\model\ data\access\

Take the TableDAO.class file, jam it back into your studio.war file, and you’re good to go – assuming you haven’t increased that value over 4,000 characters! There’s still one more glitch in this journey

100% CPU in Collaboration Server on Solaris?

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.


Collab periodically starts chewing up CPU until it maxes out the box and ultimately dies.


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:

Here’s the rundown on the diagnosis we did (Collab on Solaris)

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(
- waiting to lock <0xffffffff40927c48> (a org.apache.coyote.http11.InternalNioOutputBuffer)
at org.apache.coyote.http11. InternalNioOutputBuffer.access$000(
at org.apache.coyote.http11. InternalNioOutputBuffer$SocketOutputBuffer.
at org.apache.coyote.http11. filters.ChunkedOutputFilter.doWrite(

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.

Update the Collab JVM to a recent release of the 1.6 JDK (1.6u23 for example).  Restart Collab

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.

Java 1.6.0_24 Breaks Collaboration Server Bulk Upload

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” access denied ( C:\Documents and Settings\Administrator\My Documents read)
at Source)
Exception occurred during event dispatching: access denied ( C:\Documents and Settings\Administrator\My Documents read)
at Source)
at bulkupload.BulkUploadApplet. chooseFiles(
at bulkupload.BulkUploadApplet. access$100(
at bulkupload.BulkUploadApplet$ (

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$ Source)
at java.awt.EventQueue$ Source)
at Method)
at$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 Source)


Increase WCI Collaboration Server Memory Settings

Friday, July 9th, 2010

The Plumtree Server stack has had a long history, forming a decent patchwork of usable applications, but never quite getting to the point where every part of the stack is consistently configured.  When it became ALUI (AquaLogic User Interaction), there was a movement towards putting configuration settings in one place – the Configuration Manager – but unfortunately now that Oracle is holding the reins and the future of the stack is in question, it looks like we’ll never have that utopian vision of single, centralized way of configuring all applications the same way.

Case in point:  configuring the memory parameters for Collaboration Server.  While Publisher utilizes a config file for memory settings, Collaboration Server passes memory parameters via the service startup path.  So, if you’ve got a decently large Collaboration install, you might find that you’re running relatively low on memory:

To up the amount of RAM available to Collaboration Server, you need to edit the registry (and yeah, back it up first!).  The key you need to change is in HKLM\ SYSTEM\ CurrentControlSet\ Services\ ptcollaborationserver, and it’s called “ImagePath”:

Change the “-Xmx” value to something larger, restart Collab, and you’ll have more RAM breathing room: