How Snapshoting works with EAP 6

This simple little guide shows more or less how a snapshot works with EAP 6. I’ll show what happens to a deployable when a snapshot is taken between another version of the app without a name change and the newer version is deployed on the same server.

I am using a standard configuration file from JBoss EAP 6.1.1, though the same will hold true for any configuration file.

Use Case

  1. Deploy war, take snapshot, deploy updated archive with different name and same runtime name, disable initial war, reload,
Deploy war archive
$ JBOSS_HOME/bin/jboss-cli.sh -c --command="deploy --name=snap1 snapshot-test.war --runtime-name=snapshot-test.war"
verify deployment
$ JBOSS_HOME/bin/jboss-cli.sh -c --command="deploy -l"
NAME  RUNTIME-NAME      ENABLED STATUS
snap1 snapshot-test.war false   STOPPED
Take snapshot
$ JBOSS_HOME/bin/jboss-cli.sh -c --command=":take-snapshot"
{
    "outcome" => "success",
    "result" => "/opt/app/jboss/jboss-eap-6.1/standalone/configuration/standalone_xml_history/snapshot/20141104-12283814720141104-113544608snapshot-uc-1.xml"
}
Disable War

The archive needs to be disabled or else the container will simply use the first instance of the war, since both of the deployables will have the same name.

$ JBOSS_HOME/bin/jboss-cli.sh -c --command="/deployment=snap1:undeploy()"
Deploy second archive
$ JBOSS_HOME/bin/jboss-cli.sh -c --command="deploy --name=snap2 tweaked-war/snapshot-test.war --runtime-name=snapshot-test.war"
verify deployment
$ JBOSS_HOME/bin/jboss-cli.sh -c --command="deploy -l"
NAME  RUNTIME-NAME      ENABLED STATUS
snap1 snapshot-test.war false   STOPPED
snap2 snapshot-test.war true    no metrics available
You will may have to reload the server for the container to recongnize the newer reference to the archive
Take snapshot
$ JBOSS_HOME/bin/jboss-cli.sh -c --command=":take-snapshot"
{
    "outcome" => "success",
    "result" => "/opt/app/jboss/jboss-eap-6.1/standalone/configuration/standalone_xml_history/snapshot/20141104-12315947120141104-113544608snapshot-uc-1.xml"
}
Stop current instance of EAP
$ JBOSS_HOME/bin/jboss-cli.sh -c --command="shutdown"
Start EAP with first snapshot
$ JBOSS_HOME/bin/standalone.sh -c standalone_xml_history/snapshot/20141104-12283814720141104-113544608snapshot-uc-1.xml -b 0.0.0.0 &
verify deployment
$ JBOSS_HOME/bin/jboss-cli.sh -c --command="deploy -l"
NAME                 RUNTIME-NAME         ENABLED STATUS
snap1                snapshot-test.war    true    OK
Stop current instance of EAP
$ JBOSS_HOME/bin/jboss-cli.sh -c --command="shutdown"
Start EAP with second snapshot
$ JBOSS_HOME/bin/standalone.sh -c standalone_xml_history/snapshot/20141104-12315947120141104-113544608snapshot-uc-1.xml -b 0.0.0.0 &
verify deployment
$ JBOSS_HOME/bin/jboss-cli.sh -c --command="deploy -l"
NAME                 RUNTIME-NAME         ENABLED STATUS
snap1                snapshot-test.war    false   STOPPED
snap2                snapshot-test.war    true    no metrics available
Advertisements

disabling deployed app on Jboss EAP 6

Generally, I don’t write a blog post about something so simple as a 1 off, but seeing as others before me haven’t figured this out and I had only stumbled upon how it works after the fact of some unfruitful researching.

If you have an application deployed on EAP 6 and want to disable it from the CLI tool, look no further. It is very easy and counter intuitive, but it works and you can verify by looking at the management console, which is what I used to disable before I found out how to do it on the command line.

Deploy application

$ JBOSS_HOME/bin/jboss-cli.sh -c --command="deploy snapshot-test.war"

Verify


$ JBOSS_HOME/bin/jboss-cli.sh -c --command="deploy -l"

NAME              RUNTIME-NAME      ENABLED STATUS
snapshot-test.war snapshot-test.war true    OK

Disable application


$ JBOSS_HOME/bin/jboss-cli.sh -c --command="/deployment=snapshot-test.war:undeploy()"

Verify


$ JBOSS_HOME/bin/jboss-cli.sh -c --command="deploy -l"

NAME              RUNTIME-NAME      ENABLED STATUS
snapshot-test.war snapshot-test.war false   STOPPED

Conclusion

Why confusion, well the name for one. I guess it makes sense wrt the container, however, if you run


$ JBOSS_HOME/bin/jboss-cli.sh -c --command="undeploy snapshot-test.war"

The war content will be completed removed from the server, vice running undeploy from the /deployment=<name>:undeploy() operation, where it will just be disabled and not removed from the server.

Java Keytool fun with x86 and s390x machines

It is always a nice feeling when something working one moment and then the next it doesn’t when nothing seemingly changes. At least that is my story and I’m sticking to it.

So while I was out on vacation, well prior to, I gave instructions to my colleagues on how to do a simple update to our RPM spec (running RHEL 6 obvi) and I knew it worked, because I tested it. Anyways, my instructions were simple and all they had to do was run the rpm after they built in on the s390x boxes. No problem right? Wrong… The RPM built and installed fine, but the keystore (baked into rpm) could not be decrypted using the same credentials as always.


$ keytool -list -v -alias myalias -keystore my.keystore -storetype jceks -keyalg AES
keytool error (likely untranslated): java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector

Weird… So I was able to narrow the issue to the JDK versions, because I was able to decrypt the keystore on x86 box without issue, but when I copied over to s390x the same keystore couldn’t be decrypted with the same params…

Now you’re probably thinking, what that is so obvious these are two different architectures, duh. Well, I would agree however I couldn’t imagine that the implementation of the encryption algorithims would change and/or be incompatible between archs AND when I created the rpm initially I tested that the keystore could be decrypted on both machines…

Anyway, lesson learned always make sure to build your keystores in each architecture.

🙂