Installera Mule och påför generella runtimeberoenden
- Följ rekommenderad instruktion för att installera Mule på https://code.google.com/p/soi-toolkit/wiki/IG_RT_MuleESB.
Ladda ner ActiveMQ-jar (ActiveMQ 5.6.0) från från följande länk och tillför den på <MULE_HOME>/lib/shared/default/.
Notera att det är viktigt att ActiveMQ-jar ligger under <MULE_HOME>/lib/shared/default/ för att inte orsaka problem med att applikationsloggar hamnar i fel logfiler (andra applikationers logfiler).
Minnesparametrar
Se över minnesinställningar för heapsize på Mule installationen
I NTjP, den nationella instansen av SKLTP används följande inställningar vad gäller heapsize för Mule på en server med 8GB arbetsminne.
<MULE_HOME>/conf/wrapper.conf
# Initial Java Heap Size (in MB) #wrapper.java.initmemory=3 wrapper.java.initmemory=1536 # Maximum Java Heap Size (in MB) #wrapper.java.maxmemory=512 wrapper.java.maxmemory=1536
Se över minnesinställningar för MaxPermSize på Mule installationen
Enligt http://www.mulesoft.org/jira/browse/MULE-6544 så sätts MaxPermSize till 256m. Om det finns behov av att uppdatera denna parameter, tex för att klara av fler applikationer i samma Mule instans, så behövs följande konfiguration uppdateras i filen <MULE_HOME>/bin/additional.groovy:
// increase max PermGen space size
// IBM JVM doesn't have a notion of the PermGen space
if (!System.properties."java.vm.vendor".toUpperCase().contains("IBM")) {
w << "wrapper.java.additional.${paramIndex++}=-XX:MaxPermSize=512m\n"
}
verifiera ändringen genom att gå in i Mule Management Console och titta på värdet Perm Gen enligt bilden nedan.
Konfigurera loggning
log4j.properties
Default konfigureras loggning i Mule i <MULE_HOME>/conf/log4j.properties. Varje applikation som driftsätts i Mule rekommenderas bära sin egen konfigurationsfil för loggning, som styr vart applikationen skall logga och hur det skall loggas.
Nedan en rekommenderad konfiguration av loggning i Mule:
# Default log level log4j.rootCategory=INFO, console log4j.appender.console=org.apache.log4j.ConsoleAppender log4j.appender.console.layout=org.apache.log4j.PatternLayout log4j.appender.console.layout.ConversionPattern=%-5p %d [%t] %c: %m%n ################################################ # You can set custom log levels per-package here ################################################ # Reduce noise for Mule High Availability log4j.logger.com.gigaspaces=ERROR log4j.logger.com.j_spaces=ERROR log4j.logger.com.sun.jini=ERROR log4j.logger.net.jini=ERROR # CXF is used heavily by Mule for web services log4j.logger.org.apache.cxf=WARN # Apache Commons tend to make a lot of noise which can clutter the log. log4j.logger.org.apache=WARN # Reduce startup noise log4j.logger.org.springframework.beans.factory=WARN # Mule classes log4j.logger.org.mule=INFO log4j.logger.com.mulesoft=INFO
wrapper.conf
I <mule_home>/wrapper.conf kan man konfigurera loggning, tex storlek på mule.log (mule_ee.log).
#******************************************************************** # Wrapper Logging Properties #******************************************************************** # Format of output for the console. (See docs for formats) wrapper.console.format=M # Log Level for console output. (See docs for log levels) wrapper.console.loglevel=INFO # Log file to use for wrapper output logging. wrapper.logfile=%MULE_BASE%/logs/%MULE_APP%.log # Format of output for the log file. (See docs for formats) wrapper.logfile.format=M # Log Level for log file output. (See docs for log levels) wrapper.logfile.loglevel=INFO # Maximum size that the log file will be allowed to grow to before # the log is rolled. Size is specified in bytes. The default value # of 0, disables log rolling. May abbreviate with the 'k' (kb) or # 'm' (mb) suffix. For example: 10m = 10 megabytes. wrapper.logfile.maxsize=1m # Maximum number of rolled log files which will be allowed before old # files are deleted. The default value of 0 implies no limit. wrapper.logfile.maxfiles=10 # Log Level for sys/event log output. (See docs for log levels) wrapper.syslog.loglevel=NONE
Stoppa och starta Mule
Hantera start och stop av Mule
På soi-toolkits hemsida finns det instruktioner för hur Mule start/stop hanteras på ett rekommenderat sätt.
Säkerställ att applikationer startas i en viss ordning
Det går att kontrollera vilken ordning applikationer skall startas i Mule, tex att Virtualiseringsplattformen skall startas före Engagemangsindex. Detta beskrivs här http://www.mulesoft.org/documentation/display/current/Application+Deployment. Notera att för att kunna använda en viss given startordning måste alla applikationer som skall startas upp anges i listan, det finns i nuläget ingen möjlighet att ange tex en applikation och * för att starta resten av applikationerna efter den första.
Ett exempel på hur detta ser ut i fallet VP startas före EI:
<MULE_HOME>/bin ./mule start -app vp-services-2.2.0-RC2:skltp-ei-application-mule-backend-app-1.0.0-RC6:skltp-ei-application-mule-frontend-app-1.0.0-RC6
Nedan är ett exempel från NTjP, där startordningen på applikationer definierats i ett script med filnamn start.sh.
Notera att det måste vara :' i slutet av alla APPLICATIONS rader, utom den sista
#!/bin/bash
AMQ_HOME=/home/mule/tp/apache-activemq-5.6.0
MULE_HOME=/home/mule/tp/mule-enterprise-standalone-3.3.1
#Applikationer som skall startas upp och i angiven ordning
APPLICATIONS='vp-services-2.2.0:'
APPLICATIONS+='skltp-ei-application-mule-frontend-app-1.0.0:'
APPLICATIONS+='skltp-ei-application-mule-backend-app-1.0.0'
echo -n "Starting ActiveMQ 5.6.0..."
cd ${AMQ_HOME}/bin
./activemq start &>/dev/null
if [ $? == 0 ]; then
echo "OK!"
fi
echo -n "Starting Mule ESB 3.3.1 and applications in given order...${APPLICATIONS}..."
cd ${MULE_HOME}/bin
# Start without teststubs
#./mule start -app ${APPLICATIONS} 2>&1 >/dev/null
./mule start -app ${APPLICATIONS} >/dev/null
if [ $? == 0 ]; then
echo "OK!"
fi
exit 0
Tillåta uppkoppling till Mule med JMX
För att kunna koppla upp sig mot Mule med JMX krävs följande konfiguration av port och läsenord i <MULE_HOME>/conf/wrapper.conf. Läs mer om parametrar på http://www.mulesoft.org/documentation/display/current/JMX+Management.
wrapper.java.additional.4=-Dcom.sun.management.jmxremote.port=<port nr> wrapper.java.additional.5=-Dcom.sun.management.jmxremote.password.file=%MULE_HOME%/conf/jmx.password wrapper.java.additional.6=-Dcom.sun.management.jmxremote.ssl=false
Skapa filen %MULE_HOME%/conf/jmx.password enligt nedan och sätt lösenord på de 2 rollerna monitorRole och controlRole.
############################################################## # File permissions of the jmxremote.password file ############################################################## # Since there are cleartext passwords stored in this file, # this file must be readable by ONLY the owner, # otherwise the program will exit with an error. # # The file format for password and access files is syntactically the same # as the Properties file format. The syntax is described in the Javadoc # for java.util.Properties.load. # Typical password file has multiple lines, where each line is blank, # a comment (like this one), or a password entry. # # # A password entry consists of a role name and an associated # password. The role name is any string that does not itself contain # spaces or tabs. The password is again any string that does not # contain spaces or tabs. Note that passwords appear in the clear in # this file, so it is a good idea not to use valuable passwords. # # A given role should have at most one entry in this file. If a role # has no entry, it has no access. # If multiple entries are found for the same role name, then the last one # is used. # # In a typical installation, this file can be read by anybody on the # local machine, and possibly by people on other machines. # For # security, you should either restrict the access to this file, # or specify another, less accessible file in the management config file # as described above. # monitorRole <some password> controlRole <some password>
Filen jmx.password skall endast ha rättigheter att kunna läsas av användaren, inga andra rättigheter, för att Mule skall starta. Detta kan man på linux åstadkomma med följande.
$chmod 400 jmx.password
Anvisningar för rättningar av Mule
Sammanställning av de Mule-rättningar som är aktuella för SKLTP
CData element tas ej om hand (ignoreras ej av xml parsern)
SKLTP-217
JIRA: SKLTP-217
Kort beskrivning: I de fall konsumenter skickar in CData element i sin request hanteras inte detta korrekt i Mule och följden blir att konsumenten får ett fel tillbaka. Läs mer i JIRA för detaljerad information.
Länk till nedladdning: patches-mule-3.3.1-fix-cdata-MULE-8941-1.0.jar
Verifiera rättningen: Med följande soapUI projekt, patches-mule-3-3-1-fix-cdata-soapui-project.xml. Förväntat resultat är att CData returneras i response.
Tesat på Mule version: Mule CE 3.3.1, Mule EE 3.3.1
Installationsanvisning för Mule-rättning
Ladda ner rättning från angiven länk i tabellen över rättningar ovan.
wget https://skl-tp.atlassian.net/wiki/download/attachments/4325452/patches-mule-3.3.1-fix-cdata-MULE-8941-1.0.jar?api=v2
Kopiera rättningen till installerad Mule
cp patches-mule-3.3.1-fix-cdata-MULE-8941-1.0.jar /usr/local/mule-standalone-3.3.1/lib/user/
Starta om Mule enligt instruktion som ni följer, tex
sudo service mule_ce_3.3.1 restart
- Verifiera rättningen
Verifiera rättningen med angiven anvisning för respektive rättning.