Over time docker eat up the disk space of the host. Here’s a script to keep it under control.
Use with care.
curl -fsSL https://git.io/voKIi | sh
Slick i otwarte sterowniki do komercyjnych baz
W wersji 2.0 Slicka firma Typesafe usunęła sterowniki (profile) do komercyjnych baz (Oracle, IBM DB2 i Microsoft SQL Server) i zaczęła pobierać za nie opłaty. Był to ruch w pełni legalny z punktu widzenia licencji BSD and Apache OSS ale jednocześnie bardzo irytujący – nie tyle ze względu na koszty ile biurokratyczne wyzwania związane z uzyskaniem zgody na zakup jakiejkolwiek dodatkowych licencji w typowym projekcie . Ruch ten spotkał się ostrą krytyką i zaowocował powstaniem sterowników wspieranych przez społeczność i dostępnych na licencji Copyleft (LGPL) – FreeSlick.
Monitoring WildFly Using BTrace
Today I was hoping to use BTrace to track a rather anoying bug in web application running inside WildFly application server. I’ve used BTrace some times in the past and my experience was nothing but positive. Until today, that is.
Probe deployment caused a myriad of exceptions inside application server coming from instrumented classes and all caused by missing btrace runtime. The classloader separation of the AS getting in my way! I know a thing or two about classloading in WildFly, so I decided to add btrace to system packages(just like Byteman)
jboss.modules.system.pkgs=org.jboss.byteman,com.sun.btrace
To my suprise, it wasn’t the end of the story because now my btrace script was unavailable
java.lang.ClassNotFoundException: TracingScript$1 from [Module "deployment.atrem.incubator.e5.ml-web.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) ... 120 more
My solution was to place tracing script in non-root package btrace.scripts
package btrace.scripts;
import com.sun.btrace.*;
import com.sun.btrace.annotations.*;
import static com.sun.btrace.BTraceUtils.*;
@BTrace
public class TracingScript {
//
}
and add the package itself to system packages
jboss.modules.system.pkgs=org.jboss.byteman,com.sun.btrace,btrace.scripts
– which finally made it work. Now, back to the problem at hand.
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
javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: JBOSS-LOCAL-USER: javax.security.sasl.SaslException: Failed to read server challenge [Caused by java.io.FileNotFoundException: /Users/Jarek/dev/wildfly-8.2.0.Final/standalone/tmp/auth/local2330515126078615287.challenge (System nie może odnaleźć określonej ścieżki)] DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
When user name or password are present but invalid the error message is a little more useful
javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: JBOSS-LOCAL-USER: javax.security.sasl.SaslException: Failed to read server challenge [Caused by java.io.FileNotFoundException: /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.
Recipe
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", \
target-context=[\
"java.naming.factory.initial"="org.jboss.naming.remote.client.InitialContextFactory", \
"java.naming.provider.url"="http-remoting://localhost:8080", \
"java.naming.security.principal"="jmsuser", \
"java.naming.security.credentials"="pass"], \
quality-of-service=ONCE_AND_ONLY_ONCE, \
failure-retry-interval=10000, \
max-retries=10, \
max-batch-size=500, \
max-batch-time=50, \
add-messageID-in-header=true)
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)
end-if
add adding datasource(s)
data-source add \ --name=[DsName] \ --driver-name=jTDS \ --connection-url=jdbc:jtds:sqlserver://[DbHost]:1433/[DbName]\ --share-prepared-statements=true \ --jndi-name=java:/jdbc/[Name]\ --user-name=[DbUser] \ --password=[DbPass] \ --min-pool-size=1 \ --max-pool-size=50 \ --background-validation=true \ --background-validation-millis=600000 \ --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
Jak podłączyć się JConsole do serwera WildFly
Ogólnie
%JBOSS_HOME%\bin\jconsole service:jmx:http-remoting-jmx://[HOST]:[MANAGEMENT_PORT]
W przypadku połączenia do serwera uruchomionego lokalnie nie jest najczęściej wymagana autoryzacja
%JBOSS_HOME%\bin\jconsole service:jmx:http-remoting-jmx://127.0.0.1:9990
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 com.sun.management:type=HotSpotDiagnostic lub korzystając z programu jinfo z JDK.
