JMS bridge between WildFly instances

I was recently trying to set up JMS bridge between two standalone WildFly instances, each running on different machine. The whole experience turned out to be less straightforward than I had anticipated and I decided I should share the solution here to hopefully help others.

The solution

It turns out that to configure JMS bridge for remote servers credentials need to be specified twice. The username and password must be added to the context to allow JNDI registry lookup and then again in destination configuration. The user referred in <user> tag must be registered in ApplicationRealm with permission to consume/send messages (depending on whether source or target is remote endpoint)

The problem

Before connection to JMS queue can be established , JMS bridge must first  lookup remote objects  (queues and connection factories) by their JDNI names. When both bridge and remote broker are running on the same machine no authentication is required, but for truly remote  lookup to succeed valid credentials are needed. It’s worth mentioning that the user used for JDNI lookup can be different from the one used for creating the JMS connection and doesn’t need permission to modify queue.

Failure to provide credentials in context definition will result in rather cryptic error Authentication failed: all available authentication mechanisms failed:
JBOSS-LOCAL-USER: Failed to read server challenge [Caused by /Users/Jarek/dev/wildfly-8.2.0.Final/standalone/tmp/auth/local2330515126078615287.challenge (System nie może odnaleźć określonej ścieżki)]
DIGEST-MD5: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by]

When user name or password are present but invalid the error message is a little more useful Authentication failed: all available authentication mechanisms failed:
JBOSS-LOCAL-USER: Failed to read server challenge [Caused by /Users/Jarek/dev/wildfly-8.2.0.Final/standalone\tmp\auth\local6004500283609774891.challenge (System nie może odnaleźć określonej ścieżki)]
DIGEST-MD5: Server rejected authentication

Only components that are registered within the java:jboss/exported/ namespace are remote accessible via the naming service.


In WildFly, JMS bridge between local and remote destinations  jms/queue/sourceQ ⇒ jms/queue/targetQ with ONCE_AND_ONLY_ONCE QoS can be created with following CLI command

/subsystem=messaging/jms-bridge=jms-bridge-name/:add(source-destination="jms/queue/sourceQ", \ 
    source-connection-factory="ConnectionFactory", \
    target-destination="jms/queue/targetQ", \
    target-connection-factory="jms/RemoteConnectionFactory", \
    target-user="jmsuser", \
    target-password="pass", \
        "java.naming.factory.initial"="org.jboss.naming.remote.client.InitialContextFactory", \
        "java.naming.provider.url"="http-remoting://localhost:8080", \
        ""="jmsuser", \
        ""="pass"], \
    quality-of-service=ONCE_AND_ONLY_ONCE, \
    failure-retry-interval=10000, \
    max-retries=10, \
    max-batch-size=500, \
    max-batch-time=50, \

Setting up jTDS with Wildfly

Setting up jTDS JDBC driver and creating datasource in Wildfly is pretty easy with CLI. It involes installing JDBC driver

# Add jTDS JDBC driver as a module
module add --name=net.sourceforge.jtds --resources=/path/to/jtds.jar --dependencies=javax.api,javax.transaction.api
# Add driver configuration
if (outcome != success) of /subsystem=datasources/jdbc-driver=jTDS/:read-resource
    /subsystem=datasources/jdbc-driver=jTDS/:add(driver-name=jTDS, driver-module-name=net.sourceforge.jtds, driver-class-name=net.sourceforge.jtds.jdbc.Driver, driver-xa-datasource-class-name=net.sourceforge.jtds.jdbcx.JtdsDataSource)

add adding datasource(s)

data-source add \
--name=[DsName] \
--driver-name=jTDS \
--share-prepared-statements=true \
--user-name=[DbUser] \
--password=[DbPass] \
--min-pool-size=1 \
--max-pool-size=50 \
--background-validation=true \
--background-validation-millis=600000 \

Jak ustawić parametr -XX:+HeapDumpOnOutOfMemoryError w serwerze WildFly

Należy w pliku „%JBOSS_HOME%\bin\standalone.conf.bat” ustawić parametry -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<hprof-dump-dir zamieniając linię
set „JAVA_OPTS=-Xms64M -Xmx512M -XX:MaxPermSize=256M”set „JAVA_OPTS=-Xms64M -Xmx512M -XX:MaxPermSize=256M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=F:\memory-dumps”

Alternatywnym sposobem jest ustawienie zmiennej środowiskowej JAVA_OPTS – skrypt uruchamiający serwer standalone.bat ją uwzględnia.

Można to zrobić na działającym systemie korzystając z JConsole i operacji setVMOption mbeana lub korzystając z programu jinfo z JDK.

JavaScript Webapps with Gradle

Shine Technologies

Duke_the_Ripper IAP4377

Gradle is a build tool on the JVM platform that’s been gaining prominence over the last few years. Gradle’s reach doesn’t stop with JVM languages though.  The most recent releases, 1.10 and 1.11, have improved support for compiling native code (C / C++ / Objective C) and introduced support for the .NET platform. For Android projects, Google have made Gradle the de facto build tool. It’s getting a name for its flexibility, so when the opportunity came to build a single page Javascript webapp we decided to put the latest addition to the polyglot build tool arsenal through its paces.

View original post 4 290 słów więcej

Adding Features to an existing Product

...code is the easy part...

Normally when building an eclipse product using Tycho, you specify all the features you require in the .product file. This creates a single root level IU. There are various situations where this is not desirable. For example you may have a core product with add-ons features – much like Eclipse itself – but only maintain a single .product file. You may also wish to be able to update some features without needing to rebuild the whole product. There is an open bug for Tycho to help with this in the future.

In this post we will concentrate on the former case. We will assume there is a prebuilt product published to a p2 repository – here we will use the Eclipse RCP product. It is possible to use these steps are part of an eclipse-repository build but you will need to adapt the default Tycho configuration to delay the product…

View original post 804 słowa więcej

Xperf Basics: Recording a Trace (the ultimate easy way)

Random ASCII

imageIf your Windows computer is running slowly – if a program takes a long time to launch, if a game has a poor frame rate, or if an idle application uses too much CPU time – the best way to investigate is to record an Event Tracing for Windows (ETW) trace. An ETW trace records a wealth of information (CPU sampling, context switches, disk I/O, custom data, and much more) that allows most performance problems to be understood by a trained expert. If you’re not a trained expert then you can still record an ETW trace, and then share it with somebody who is.

If a particular program is being slow or inefficient then you may be able to record an ETW trace and share it with the authors of that program. Quite often they can figure out what is going wrong, whether it is a bug on their side

View original post 1 048 słów więcej