Planet Jython

Last update: May 20, 2013 11:47 PM

February 19, 2013

Ever wondered how a JVM reacts to various kill signals? The (intended) behaviour might be documented somewhere already, but I found having a table of the actual behaviour available quite useful. In particular I wanted to know which kill signals trigger the JVM to run registered shutdown hooks, and which kill signals don't actually terminate the JVM. So I decided to compile a table of that information.

I wrote up a small Java application that just registers a shutdown hook that I can detect whether it has executed or not, and then sleeps until I get a chance to kill it:

class Death {
  public static void main(String... args) throws Exception {
    Runtime.getRuntime().addShutdownHook( new Thread(){
      @Override
      public void run()
      {
        System.out.println("Shutting down");
      }
    } );
    for (;;) Thread.sleep(100);
  }
}

Then I ran the program in one terminal window (java Death; echo $?) while iterating through all kill signals (0-31) in another:

kill -$SIGNAL $(jps | grep Death | cut -d\  -f1)

signal	shutdown	runs hook	exit code	comment
default (15)	yes	yes	143	SIGTERM is the default unix kill signal
0	no	-	-
1 (SIGHUP)	yes	yes	129
2 (SIGINT)	yes	yes	130	SIGINT is the signal sent on ^C
3 (SIGQUIT)	no	-	-	Makes the JVM dump threads / stack-traces
4 (SIGILL)	yes	no	134	Makes the JVM write a core dump and abort on trap 6
5	yes	no	133	Makes the JVM exit with "Trace/BPT trap: 5"
6 (SIGABRT)	yes	no	134	Makes the JVM exit with "Abort trap: 6"
7	yes	no	135	Makes the JVM exit with "EMT trap: 7"
8 (SIGFPE)	yes	no	134	Makes the JVM write a core dump and abort on trap 6
9 (SIGKILL)	yes	no	137	The JVM is forcibly killed (exits with "Killed: 9")
10 (SIGBUS)	yes	no	134	Emulates a "Bus Error"
11 (SIGSEGV)	yes	no	134	Emulates a "Segmentation fault"
12	yes	no	140	Makes the JVM exit with "Bad system call: 12"
13	no	-	-
14	yes	no	142	Makes the JVM exit with "Alarm clock: 14"
15 (SIGTERM)	yes	yes	143	This is the default unix kill signal
16	no	-	-
17	no	-	145	Stops the application (sends it to the background), same as ^Z
18	no	-	146	Stops the application (sends it to the background), same as ^Z
19	no	-	-
20	no	-	-
21	no	-	149	Stops the application (sends it to the background), same as ^Z
22	no	-	150	Stops the application (sends it to the background), same as ^Z
23	no	-	-
24	yes	no	152	Makes the JVM exit with "Cputime limit exceeded: 24"
25	no	-	-
26	yes	no	154	Makes the JVM exit with "Virtual timer expired: 26"
27	yes	no	155	Makes the JVM exit with "Profiling timer expired: 27"
28	no	-	-
29	no	-	-
30	yes	no	158	Makes the JVM exit with "User defined signal 1: 30"
31	yes	no	134	Makes the JVM exit on Segmentation fault

This list was compiled using (a quite old) Oracle Hotspot Java 8 EA on Mac OS X:

java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b65)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b09, mixed mode)

Hope this is useful to more people than myself.

February 19, 2013 10:45 AM

February 10, 2013

Frank Wierzbicki

Jython 2.7 beta1 released!

On behalf of the Jython development team, I'm pleased to announce that the first beta of Jython 2.7 is available. I'd like to thank Adconion Media Group for sponsoring my work on Jython. I'd also like to thank the many contributors to Jython.

Jython 2.7b1 brings us up to language level compatibility with the 2.7 version
of CPython. We have focused largely on CPython compatibility, and so this
release of Jython can run more pure Python apps then any previous release.
Please see the NEWS file for detailed release notes. Some notable new features
in this release are: a bytearray implementation, a buffer api, memoryview, and a
bz2 module.

As the first beta release, this marks a change in the focus of development
from adding features to bug fixing and on getting more of the test suite
running properly.

This release is being hosted at maven central. The traditional installer can be found here. See the installation instructions for using the installer. Three other versions are available:

A pre-built standalone version (see the installation instructions for details about standalone mode).
A jython.jar (like the standalone version but without the bundled python files).
A source only distribution.

To see all of the files available including checksums, go here and navigate to the appropriate distribution and version.

February 10, 2013 02:35 PM

Jython 2.5.4 rc1 released!

On behalf of the Jython development team, I'm pleased to announce that the first release candidate of Jython 2.5.4 is available. I'd like to thank Adconion Media Group for sponsoring my work on Jython. I'd also like to thank the many contributors to Jython.

This release is being hosted at maven central. The traditional installer can be found here. See the installation instructions for using the installer. Three other versions are available:

A pre-built standalone version (see the installation instructions for details about standalone mode).
A jython.jar (like the standalone version but without the bundled python files).
A source only distribution.

To see all of the files available including checksums, go here.

This release fixes numerous bugs since the 2.5.3 release of Jython. Some highlights include:

The file upload fix for Tomcat and Jetty has been changed.
Some NullPointerExceptions where fixed.

See the NEWS file for details.

Please report any bugs that you find. Thanks!

February 10, 2013 02:25 PM

January 21, 2013

James Abley

How to convert an Oracle .dmp into a more portable format

One of the things that I've come across has been legacy applications which use Oracle; where we don't have access to the database, but do get provided with Oracle .dmp files. These aren't very helpful when all you have (or are used to!) is MySQL and PostgreSQL.
One approach that I've had success with is to download a VirtualBox image of Oracle, and then play with the data in there. I chose the Database App Development VM since I wasn't sure what parts of Oracle I'd need, having strenuously, pretty successfully, avoided Oracle for most of my time in the industry.
I then imported this into VirtualBox (running on OSX Lion) and configured networking:

One adapter running NAT so that I can browse the internet in the guest OS. This let me download the .dmp file to the guest OS filesystem.
Set up Port Forwarding for the NAT interface so that I can ssh to port 2022 on the host which will go to port 22 on the guest, thus allowing ssh access.
Optionally, I set up the VM to have another adapter (Host-only) so that I can set up NFS shares to mount part of the host filesystem under the guest.

Next, I needed to get the .dmp data onto the guest OS (and later get the transformed data off the guest). ssh-copy-id is good for this, to put an SSH public key into the authorized_keys for the oracle user on the guest. You can also get data into and out of the guest using python -m SimpleHTTPServer ran in the appropriate directory, which let me browse the host filesystem or guest filesystem as needed. ifconfig in the host or guest lets me know which IP address to use.
Now, I needed to create a tablespace and user to allow me to import the data. I advise doing this, since (for me at least!) importing the data is an iterative process, and creating a separate tablespace (with separate data files) is a good practice since it avoids bloating the system tablespace and means that disk space can be reclaimed. Pretty much the only Oracle knowledge I have! Before you create the tablespace, it's a good idea to check the size of your .dmp and available space on the filesystem. I had a 1.4GB .dmp which didn't fit into the space left on the fs and I burnt a bit of time figuring out Oracle error messages for the failed import before I worked out the filesystem wasn't big enough. In this case, I created a symlink in $ORACLE_HOME/dbs/ which pointed to a large enough partition and set the owner / permissions as required. Creating the tablespace was just a case of running:

$ sqlplus / as sysdba
...
SQL> CREATE BIGFILE TABLESPACE mytablespace DATAFILE 'mytablespace/f1.dat' SIZE 20M AUTOEXTEND ON;

Tablespace created.

SQL> CREATE USER myuser IDENTIFIED BY password DEFAULT TABLESPACE mytablespace;

User created.

SQL> GRANT CREATE SESSION,CREATE SYNONYM,CONNECT,RESOURCE,CREATE VIEW,IMP_FULL_DATABASE to myuser;

Grant succeeded.

SQL> exit

We should now be in a position to try to import the data.

$ time imp myuser/password file=path/to/data.dmp full=yes

If this fails since the user that it was exported as is not the same as the user you created, then stop the import and clear out the user and tablespace.

$ sqlplus / as sysdba

SQL> DROP USER myuser CASCADE;

User dropped.

SQL> DROP TABLESPACE mytablespace INCLUDING CONTENTS AND DATAFILES;

Then re-create the tablespace and the new user and try the import again.
Once the import has succeeded, you want to get the data out of the database into a less proprietary format. One way is to use SQL Developer (a GUI tool included in the VM image).
Open SQL Developer and define a new database connection:

Connection name: myuser
User name: myuser
Password: password
Save Password?: Checked

SID is orcl rather than xe, in the Developer Days VM that I used.
Test the connection. It should work. Then open the connection and examine the tables.

In the menu, click Tools | Database Export
Want to export the data only, into CSV.
Choose the connection, choose the tables, choose the destination file.

For large databases, this can take a while to process (2.5 hours for my case). It may be faster to write your own export routine using Perl, PL/SQL or similar. In the end, that's what I did, so that I could script the entire process like so:

January 21, 2013 09:24 AM