DevGrok

A while ago I posted a solution to OutOfMemoryError: unable to create new native thread , however I encountered a problem caused by the nproc setting but wasn't fixable by a simple ulimit command. The problem we were encountering was that we couldn't sudo into service account when we had all our application servers running. Our sysadmins have setup a user escalation script, which there's nothing wrong with. It does some prechecks, sudos a script under the requested user, does some logging, then does an exec <configured shell> . When there are too many processes, it manages to run the 2nd script as the user, however the exec command blocks, it never gets to the profile script to execute the ulimit command. I traced it down to the default soft limit for the number of process for all users to 1024. Our process count is way above that, which means when it tries to create a new process for bash when we run the sudo script, it can’t. So we are unable to sign into the a...

The official specs for JEE servers, say that your not meant to start your own threads, implying an impending doom if you do so. In actually you loose some functionality in terms of what the app server provides/allows and the app server isn't easily able to kill off rogue threads when you try and undeploy. Not the worst things in the world but if we could do something about it we would. The first 'standard' support for spawning threads in a container was the commonj Work Manager and Timer . It was a bit clunky to use, hard to integrate and not supported across the board. Thankfully they made the smart decision to just extend Doug Lea's framework in concurrency-ee . Integrating this into camel but substituting the used ThreadFactory with the container provided ManagedThreadFactory. The one downside of doing this is that we loose don't create the threads so we may not be able to set the name. Having said that, using a nifty trick I was able to set it on Websphere Lib...

When loading an application in an osgi-like container with an app that references jabx-impl, you might see the following warning: [WARNING ] SRVE9967W: The manifest class path jaxb-api.jar can not be found in jar file file:/D:/Java/maven/repo/com/sun/xml/bind/jaxb-impl/2.2.7/jaxb-impl-2.2.7.jar or its parent. [WARNING ] SRVE9967W: The manifest class path jaxb-core.jar can not be found in jar file file:/D:/Java/maven/repo/com/sun/xml/bind/jaxb-impl/2.2.7/jaxb-core.jar.jar or its parent. This one is caused by the specific reference to jaxb-api.jar and jaxb-core.jar in jaxb-impl-2.2.7.jar/META-INF/MANIFEST.MF: Class-Path: jaxb-api.jar jaxb-core.jar The artifacts that maven pull in have a different filename (with a version number) that doesn't match the expected build version. e.g. jaxb-core-2.2.7.jar and jaxb-api-2.2.7.jar The solution: Create 2 empty zip files and name them jaxb-core.jar and jaxb-api.jar Place them into proj/src/main/WEB-INF/lib Done

SQL Server's lock hints allow to you to use it as a database queue. The general process is discussed on stackoverflow . Here I wanted to summarise the different ways it can be configured with the camel-jpa component. Testing was done against SQL Server 2008 R2 Developer Edition. The list of locks was obtained using this useful script from Microsoft . Assume we have a generic entity: @Entity public class JpaMessage { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; /** an optional hint as to type of message */ private String msgType; /** a refrence to another table containing the blob for performance reasons */ private Long msgBlobId; /** to allow for PESSIMISTIC locking */ @Version private Date lastUpdated; } /** basic route */ public class TestRoutbuiler extends BaseRouteBuilder { @Value("${endpoint.uri}") private String endpointUri; @Override public void configure() throws Exception { ...

Setting the necessary properties on the Java Client for MQ libraries in order to pass the ApplIdentityData is quiet simple, as mentioned in this stackoverflow post : MQDestination queue; //... queue.setBooleanProperty(WMQConstants.WMQ_MQMD_WRITE_ENABLED, true); queue.setBooleanProperty(WMQConstants.WMQ_MQMD_READ_ENABLED, true); queue.setIntProperty(WMQConstants.WMQ_MQMD_MESSAGE_CONTEXT, WMQConstants.WMQ_MDCTX_SET_ALL_CONTEXT); javax.jms.Message message; //... message.setStringProperty(JmsConstants.JMS_IBM_MQMD_APPLIDENTITYDATA, "...."); The meaning of the properties is listed in the documentation: Destination object properties . If using Websphere Application Server, you can define a Jms Queue as a Resource which can be intern looked up via JNDI. IBM has a pretty good summary of the different methods. How to read and write fields from the MQMD via WebSphere MQ Classes for JMS Version 7: direct, using JNDI and using WebSphere Application Server . To set it up in WAS7 f...

The compile time woven aspectj spring-aspects provides some very useful features. The features I was after was: transactional boundaries between methods in the same bean. e.g. nonTransactionMethod() calling requiresNewMethod() without having to use self references or manually handling the transactions. consistent results between testing in Eclipse, testing via maven and running on the server (instead of using the loadtime weaver) During testing in both eclipse and maven I started getting exceptions of the likes "NoTransactionException". The individual test would pass fine but when running all the tests together they would fail. Debugging through the tests showed that transaction manager was still being called but it was the wrong one! Decompiling the aspectj woven code shows the reason. My simple class: package net.devgrok; import org.springframework.transaction.annotation.Transactional; import org.springframework.transaction.aspectj.AbstractTransactionAspect; impo...

(This was tested on Red Hat EL6 JDK 1.6.31 64-bit) If you've ever come across this error, it can be very misleading. Caused by: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:640) The common suggestion (as the error suggests) is a memory related problem. Some tips but ultimately unhelpful: http://candrews.integralblue.com/2009/01/preventing-outofmemoryerror-native-thread/ http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html The common theme amongst all of them is the stack size. Came across this post with same test code: http://www.odi.ch/weblog/posting.php?posting=411 However the tests were inconsistent, modified it to only go 50 calls deep. Modified code here . We discovered that changing the options made very little difference to the maximum number of threads. Originally we thought it...