Blat is a handy Win32 console utility that enables you to send emails via the command line, on Windows machines. This is especially useful within batch scripts.

Given below are some how-tos on basic uses of blat. Refer the blat syntax page for more options with blat. The commands below have been tested on Windows Server 2003 with blat v2.6.2, unless otherwise stated.

HOW-TO 1: Configure the SMTP Relay for blat

The blat utility can perform functions of both an MUA and an MTA. Before using blat, you may configure certain options in the Windows Registry to avoid typing them repeatedly whenever sending emails (using overrides on the command line). An example configuration is given below:

blat -installSMTP mymailer.smtp.xyz.com sender@xyz.com 5 25
#
# where:
# mymailer.smtp.xyz.com => SMTP Relay host's domain name
# sender@xyz.com => sender's email address
# 5 => Number of retries (default=1)
# 25 => SMTP Server port (default=25)
#

After executing the command in the above example, your Windows Registry should have entries for blat as shown in the image below:

HOW-TO 2: Send email with empty body

blat -s "Test mail" -i "Cybergavin Tester" -to test@abc.com -body " "
#
# where:
# -s => Subject (NOTE: If you don't provide a subject, then default subject is
#     "Contents of file: stdin.txt"
# -i => Sender's Name (NOTE: Sender's email address already configured in STEP 1)
# -to => Recipient's Email Address
# -body => blank body (blankspace within double-quotes)
#

NOTE: To send email with a body, just type the message within double-quotes in the -body option.

HOW-TO 3: Send email with body from a file

blat body.txt -s "Test mail" -i "Cybergavin Tester" -to test@abc.com
#
# where:
# -s => Subject (NOTE: If you don't provide a subject, then default subject is
#     "Contents of file: stdin.txt"
# -i => Sender's Name (NOTE: Sender's email address already configured in STEP 1)
# -to => Recipient's Email Address
# body.txt => file containing message body
#

HOW-TO 4: Send attachment(s)

blat -s "Test mail" -i "Cybergavin Tester" -to test@abc.com -body "Please see attached"
 -attach test.txt
#
# where:
# -s => Subject
# -i => Sender's Name
# -to => Recipient's Email Address
# -body => Message Body
# -attach => Binary File to be attached
#

HOW-TO 5: Send HTML email

blat body.html -s "Test mail" -i "Cybergavin Tester" -to test@abc.com -html
#
# where:
# -s => Subject (NOTE: If you don't provide a subject, then default subject is
#     "Contents of file: stdin.txt"
# -i => Sender's Name (NOTE: Sender's email address already configured in STEP 1)
# -to => Recipient's Email Address
# body.html => file containing message body in HTML format
# -html => Use HTML format (Content-Type : text/html)
#

Copying a MySQL database from one server (MySQL server/host) to another may be done using a simple two-step process.

STEP 1: Backup the database on the source server

The mysqldump utility can be used to backup the database on the source server. An example using the root account is provided below:

mysqldump -u root --databases mytestdb > mytestdb.sql

NOTE:The "–databases" option above ensures that a "CREATE" statement for the database is written to the backup SQL, thereby enabling you to restore the database to a server where the empty database does not exist. If you do not use the "–databases" option before the database name, then the backup will still work, but in this case, you must have an empty database of the same name existing on the target server (no CREATE statement in SQL).

STEP 2: Restore the database on the target server

Restoring the database on the target server simply involves executing the "backup SQL" created on the source server.An example using the root account is provided below:

mysql --password=XXXXX < mytestdb.sql

Problem:

A WebLogic managed Server crashed with no relevant information whatsoever in the logs. The server was started by a Node Manager.

Background & Analysis:

WebLogic Version: 8.1 SP6 (cluster with 2 managed servers)
JVM version: 32-bit JRockit R27.6 1.4.2_21
Operating System : 64-bit RHEL 4.0 AS update 7 (kernel 2.6.9)
When the server crashed, the server and stderr logs had no clues regarding the cause of the crash. However, the stdout log was 2147483647 bytes (2 GB) as it was not rotated. The last modified time of the stdout file was the same as the time when the server crashed. The very same scenario was observed when the other server in the cluster crashed. The filesystem is large-file aware.

Solution:

Rotate and archive the stdout file, so that the JVM running WebLogic does not crash when stdout reached 2 GB in size.

NOTE: All logs (server, stderr, stdout, application) must be effectively rotated and archived. I’ve seen several enterprise environments fall victim to lack of log housekeeping. To rotate files like the JVM’s stdout and stderr, it’s best to use the copy-truncate method (make a copy of existing file and then truncate existing file) as the JVM will still have a file descriptor open for the file. You may lose a tiny amount of log information using this method, but it’s less harmful than your server crashing. Removing or renaming a file with an open file descriptor will only make the problem invisible to you as the JVM will still be writing to the old file descriptor and growing a file in a location other than your logs directory (/proc).

Root Cause:

The JVM’s stdout file reached 2GB in size.

NOTE:
(1) The solution above describes a successful problem-solving experience and may not be applicable to other problems with similar symptoms.
(2) Your rating of this post will be much appreciated. Also, feel free to leave comments.

Problem:

When a clustered application deployed on a WebLogic 8.1 SP6 cluster tries to connect to a Documentum Content Server during load tests, one or more servers in the WebLogic cluster crash with a core dump. Given below is an extract of the exception stack trace from a JRockit dump file (jrockit. .dump):

Stack 0: start=0xf3068000, end=0xf308c000, guards=0xf306d000 (ok), forbidden=0xf306b000 Thread Stack Trace: at (???.c)@0×32553338
– Java stack —
at com/documentum/dmcl/Dmcl40.get(Ljava/lang/String;)Ljava/lang/String;(Native Method)
at com/documentum/fc/connector/DfConnection.apiGet(DfConnection.java:180)
^– Holding lock: com/documentum/fc/connector/DfConnection@0x1c4a3970[thin lock]
at com/documentum/fc/connector/DfConnection.(DfConnection.java:155)
at com/documentum/fc/connector/DfConnectionFactory.getConnection(DfConnectionFactory.java:25)
at com/documentum/fc/client/DfClientSupport.getConnection(DfClientSupport.java:623)
at com/documentum/fc/client/DfClientSupport.newSession(DfClientSupport.java:183)
at com/documentum/fc/client/DfSessionManager.newManualSession(DfSessionManager.java:753)
^– Holding lock: com/documentum/fc/client/impl/session/IdentityContext@0x1ce1a2b0[thin lock]
at com/documentum/fc/client/DfSessionManager.createSessionHelper(DfSessionManager.java:627)
at com/documentum/fc/client/DfSessionManager.getSession(DfSessionManager.java:559)
^– Holding lock: com/documentum/fc/client/DfSessionManager@0x1cdfb7c0[thin lock]
at com/documentum/fc/client/DfSessionManager.getSession(DfSessionManager.java:362)

Background & Analysis:

WebLogic Version: 8.1 SP6 (cluster with 2 managed servers)
JVM version: JRockit R27.6 1.4.2_21
DFC version: 5.3 SP6
The JVM crashed whenever the application, under load, attempted to connect to the Documentum Content Server via the Documentum Foundation Classes (DFC) API. When we ran only one server in the cluster (kept the other server in shutdown state), the running server worked fine with no crashes and DFC errors.

Solution:

Upgrade DFC to version 6.0 or higher.

Workaround: If you cannot upgrade to DFC 6 or higher for some reason, then as a workaround, ensure that you have some means of "priming" your application. i.e. initiate connections (to Documentum) from your application (unit testing) on all WebLogic servers within the cluster before your application takes on load. We had to use this workaround as WebLogic 8.1 SP6 is not supported on JVM 1.5+ and DFC 6+ is only supported on JVM 1.5+.

Root Cause:

DFC 5.3 SP6 is not compatible with WebLogic clusters. It is supported only on a single WebLogic node. DFC versions 6 and higher are supported on WebLogic clusters.

NOTE:
(1) The solution above describes a successful problem-solving experience and may not be applicable to other problems with similar symptoms.
(2) Your rating of this post will be much appreciated. Also, feel free to leave comments.