[Carter Harrison]

Bumped into this problem again.  Luckily found my posts from this thread back in 2013.  Bouncing the host server got the testing tool working again.  Don’t mess with your server.ini file.

[Carter Harrison]

Hey Russ,

The ‘Use Recovery database’ option is checked on all threads in the site, but I’m not sure I see the relevance to my problem.  As you know the recovery database is used to cache messages and their current state to disk in case the engine process dies and the contents of memory are lost.  Regardless as to whether or not the recovery database is in use or not, the messages and their metadata should remain in memory so long as the process is still running and the message has not been successfully delivered.

[Carter Harrison]

Russ,

An outbound thread can definitely send messages to the error database.  That I’m am confident of because I am successfully doing it.  By returning a disposition of ‘ERROR’, the thread will re-attempt the transmission of the message up to the number of retries specified on the Outbound tab of the thread properties.  When the retries are exhausted the SEND FAIL TPS is invoked and then finally the message is sent to the error database.  The problem is that the pdupoc_write context does not seem to allow me to set the USERDATA and have it preserved up to the point where the message is finally written into the error database.  You can try this yourself by writing a very simple UPOC that does nothing but set the metadata on the message and then return a disposition of Error.

Code:

proc outboundProtocolUPOC { args } {

global HciConnName HciRoot HciSite HciSiteDir
   
#Get current mode and engine context.
keylget args MODE mode
keylget args ARGS arguments
keylget args CONTEXT context

switch -exact — $mode {
run {
keylget args MSGID messageHandle
msgmetaset $messageHandle USERDATA “My Error Message”
return [list “ERROR $messageHandle”]
}
}
}

When the message finally hits the error database it looks like the following.  Notice that the USERDATA field is not set.

Quote:

> hcidbdump -e -L -c

msg: 0x3000003c

   msgType           : DATA

   msgClass          : PROTOCOL

   msgState          : Message undeliverable within retries (405)

   msgPriority       : 5120

   msgRecoveryDbState: Log:update (3)

   msgFlags          : 0x8a02

   msgMid            : [0.0.2]

   msgSrcMid         : [0.0.0]

   msgSrcMidGroup    : midNULL

   msgHostId         : 3736122838

   msgOrigSrcThread  : conn_1

   msgOrigDestThread :

   msgSrcThread      : conn_1

   msgDestThread     :

   msgXlateThread    :

   msgSkipXlate      : 0

   msgSepChars       :

   msgNumRetries     : 2

   msgGroupId        : 0

   msgDriverControl  :

   msgRecordFormat   :

   msgRoutes         :

   msgUserData       :

   msgStaticIsDirty  : 0

   msgVariableIsDirty: 0

   msgTimeStartIb    : 1405090156.918(Fri Jul 11 10:49:16 2014)

   msgTimeStartOb    : 1405090156.918(Fri Jul 11 10:49:16 2014)

   msgTimeCurQueStart: 0.000(Wed Dec 31 19:00:00 1969)

   msgTimeTotalQue   : 10.070

   msgTimeRecovery   : 1405091900.885(Fri Jul 11 11:18:20 2014)

   msgEoConfig       : 0x0

   msgData (BO)      : 0x30000124

   message           : ‘         8  999999999          1x0a’

Previous recovery db state is 15.

[Carter Harrison]

Hey Russ,

Thanks for the response.  The unbalanced double quote was simply a typo on my side.  Obviously that unbalanced quote would cause a TCL exception.

Anyway I am thinking it is an engine bug – my code is doing more or less what yours is doing in terms of setting the metadata and returning the disposition list.

[Carter Harrison]

Hi Margaret,

I’m curious to know if you were ever successful in posting transactions to ConnectVirginia?  I have developed an HTTP protocol upoc that I am using to deliver messages to another system via HTTPS however we are also receiving error #500 when attempting to upload to ConnectVirginia’s test endpoint.

[Carter Harrison]

I’ve been experiencing extreme lag with the Cloverleaf client as well and this is when I’m on the same network as the Cloverleaf server itself.

[Carter Harrison]

OS X doesn’t actually respect that JVM setting.  Trust me, you don’t have JVM 1.5 installed on your Mac anyway.  The system will automatically default to the most recent JVM installed on your Mac.

[Carter Harrison]

Do me a favor and try replacing your Info.plist with the one I included earlier in the thread.  Give it a go and let me know if that works.

[Carter Harrison]

Ya but make sure you append it to the right portion.. I posted my entire Info.plist file for you so hopefully that will serve as a guide for you.

[Carter Harrison]

You are missing the following portion:

Code:

Properties

    HCIROOT
    $APP_PACKAGE/Contents/Resources

[Carter Harrison]

Not exactly sure.. Here are the contents of my Info.plist

Code:

CFBundleAllowMixedLocalizations
true
CFBundleDevelopmentRegion
English
CFBundleExecutable
JavaApplicationStub
CFBundleIconFile
GenericApp.icns
CFBundleIdentifier
com.hie.cloverleaf.gui.launchpad.LaunchpadApplication
CFBundleInfoDictionaryVersion
6.0
CFBundleName
Cloverleaf 5.8
CFBundlePackageType
APPL
CFBundleSignature
????
CFBundleVersion
100.0
LSMultipleInstancesProhibited

Java

ClassPath

$JAVAROOT/clgui.jar
$JAVAROOT/cljava.jar
$JAVAROOT/CmpCrmf.jar
$JAVAROOT/crysec.jar
$JAVAROOT/cscjmx.jar
$JAVAROOT/dnsns.jar
$JAVAROOT/dtfj-interface.jar
$JAVAROOT/dtfj.jar
$JAVAROOT/dtfjview.jar
$JAVAROOT/gskikm.jar
$JAVAROOT/healthcenter.jar
$JAVAROOT/ibmcmsprovider.jar
$JAVAROOT/ibmjcefips.jar
$JAVAROOT/ibmjceprovider.jar
$JAVAROOT/ibmkeycert.jar
$JAVAROOT/IBMKeyManagementServer.jar
$JAVAROOT/ibmpkcs11impl.jar
$JAVAROOT/ibmsaslprovider.jar
$JAVAROOT/ibmxmlencprovider.jar
$JAVAROOT/jaccess.jar
$JAVAROOT/jbcl3.0-res.jar
$JAVAROOT/jbcl3.0.jar
$JAVAROOT/jdmpview.jar
$JAVAROOT/jgl3.1.0.jar
$JAVAROOT/jsp-api.jar
$JAVAROOT/localedata.jar
$JAVAROOT/servlet-api.jar
$JAVAROOT/xmlencfw.jar

JVMVersion
1.6.0
MainClass
com.hie.cloverleaf.gui.launchpad.LaunchpadApplication
Properties

HCIROOT
$APP_PACKAGE/Contents/Resources

[Carter Harrison]

Yep – you missed step #8 in my instructions.  You should see a line in INFO.plist that references the HCIROOT environment variable.

[Carter Harrison]

Carson,

In the PM you sent me, you said you would attempt to launch the Cloverleaf app but then nothing would happen.

[Carter Harrison]

I was able to fix the issue.  I did two things and unfortunately I’m not sure which was the fix but it appears to be working now:

1. Went into $HCIROOT/server/server.ini and edited the “environs” line such that it did not contain any sites that no longer existed.  There was actually a large number of these.

2. Restarted the host server.

The testing tool and the engine are now using the variant from the master site properly.  I’m not sure why either of these things would have worked since the host server has nothing to do with engine processes.

[Carter Harrison]

I bounced all processes/daemons to no avail.  Technically that shouldn’t be the problem since the testing tool also is not using the variant correctly and it is not tied to any engine processes/caches at all.

The site having the issue does not have the variant in question defined within it.  The variant is only present in the master site.

As a test, I created a brand new site and copied the XLT’s from the site experiencing the issue and the new site did not exhibit the same issue.  So there is something within this one particular site that is preventing the master site variant from working properly.

[Author]

Replies