HTTP Connection - engine selector

So I changed the connector engine and restartet the test. This time I started small. I set the heap to 512MB and limited the maxProcessor to 500. What I then saw was unexpected. The engine filled up right to the ten thousand requests I send. There occured no Out-Of-Memory at all. What was also interesting was, that the engine held 10k connections despite the maxprocessors was set to 500.
So to conclude the result, the new connector is quite impressive when you need to handle a lot of simultanous connection and have not a lot of memory to spare. On the other hand, when you use it, you loose some of the TIBCO integrated features to limit your load. Further to that, the TIBCO documentation states that due to the single thread arcitecture you increase latency. So as always there is a tradeoff.

One final sidenote. I had some issues with the BusinessWorks 5.7.1 engine so I upgraded it to 5.7.2. Than it ran without a glitch.

graph.height.pref=712
graph.width.pref=1515

These values represent the default size which the Designer allocated for its canvas. As you can see the default is pretty small on this one. I also found installations where both values where ten times larger then this. So far I found no performance penalty to this.
The only pattern I found is that newer installation had smaller values as default. Where this value comes from and how it is determined stays unclear to me.

One other thing I found during my research. If the panel is to small for the current process you can drag one activity right next to the border and then start to move it via keyboard (‘Shift + Cursor’). By doing so you drag the icon out of the canvas, but the position will be updated internally. After that you just need to refresh the process view and voila you have expanded the canvas size. But this is just a quick and dirty work-around.

for the Administrator:

#!/bin/bash

DOMAIN=tibcoesb
USER=esb
TIBCO_HOME=/home/$USER/tibco
PATH=/bin:/usr/bin:/sbin:/usr/sbin
NAME=tibco-admin

start() {
# Start daemons.
echo "Starting Tibco Admin"
/bin/su $USER -c"cd $TIBCO_HOME/administrator/domain/$DOMAIN/bin;./tibcoadmin_$DOMAIN 2>&1 | /usr/bin/logger -t $NAME" &
echo "done"
}

stop() {
# Stop daemons.
echo "Shutting down Tibco Admin"
killall tibcoadmin_$DOMAIN
echo "done"
}

case "$1" in
  start)
	start
	    ;;
  stop)
	stop
    	    ;;
  *)
        echo $"Usage: $0 {start|stop}"
    	exit 2
esac

for the Hawk

#!/bin/bash

DOMAIN=tibcoesb
USER=esb
TIBCO_HOME=/home/$USER/tibco
PATH=/bin:/usr/bin:/sbin:/usr/sbin
NAME=tibco-hawk

start() {
# Start daemons.
echo "Starting Tibco Hawk"
/bin/su $USER -c"cd $TIBCO_HOME/tra/domain/$DOMAIN;./hawkagent_$DOMAIN 2>&1 | /usr/bin/logger -t $NAME" &
echo "done"
}

stop() {
# Stop daemons.
echo "Shutting down Tibco Hawk"
killall hawkagent_$DOMAIN
echo "done"
}

case "$1" in
  start)
	start
	    ;;
  stop)
	stop
    	    ;;
  *)
        echo $"Usage: $0 {start|stop}"
    	exit 2
esac

The easiest way to achieve this would be to change the authentication for this service. Unluckily this service is used by a lot of other clients, so I can’t change it out of the blue. Next thing that came to my mind was using the underlying tomcat to do some IP-based blocking. After some searching around I gave that one up. Tibco has a really complex deployment model for BusinessWorks so I wasn’t able to even find the process-specific section for the tomcat engine.
After some searching around in the documentation (actually several hours – hooray to a usable documentation) I found some parameter which allows you to block IPs with some TRA-file parameters. In case you want to look it up yourself it is in the BusinessWorks documentation under ‘Administration’ -> Chapter 8 ‘Custom Engine Properties’ -> ‘Available Custom Engine Properties’ (and another hooray to the excellent formatting – Note to Tibco: HTML has tags, so you can do more with the content then continuous text – even some breaks would enhance the experience).
So back to the point:

bw.plugin.http.server.allowIPAddresses
bw.plugin.http.server.restrictIPAddresses

Both tags are rather self explanatory so you can use right away. Tibco says you can use it with a single IP, a list of IPs (comma-separated) or regular expression. As stated before this highlight of a documentation doesn’t say what reg-exp syntax means. I guess Tibco means they use the Tomcat engine for evaluation of these values an that means they use the Java syntax described here.

For this email system a database template system was used and of course the database was an upgraded Oracle 10g, so all the columns (for historic reasons) were Latin-1 and not Unicode.

But a simple Google query even showed a solution for this problem. Oracle introduced, exactly for this case, a new data type (NCHAR – means Unicode character). After changing the table column from CLOB to NCLOB the database should have the ability to store Unicode characters, even if it is running in Latin-1 mode.

First thing I tried, was to insert a valid Russian email template into the database and lucky me, the text which was stored in the database, was still a bunch of invalid Latin-1 characters (character code 0xbf).

After quite some googling I came to this Oracle article. In that article Oracle explains a bit more how to force the JVM to use Unicode characters for the JDBC connection instead of the character set presented from the database. With nothing to lose I tried it in my designer via modifying the designer.tra (I just appended the following parameter).

 -DOracle.jdbc.defaultNChar=true

After that, it worked like a charm. Now it was possible to write Unicode characters to the new created NCLOB columns in the database.

After creating the template and doing a trial run I got curious what would happen if I removed that parameter and tried to read from the Unicode column. To my surprise it worked out-of-box. So you can read Unicode characters from an Oracle database without modifying anything. The indifferences just happen if you want to write via JDBC.

To round this up this bug is not limited to TIBCO BusinessWorks. I also tried it with a tool named DbVisualizer (also Java based) and (what really annoys me, because it is c-based and shouldn’t have this JDBC bug) tora. All showed the same result on writing to that database.