Wildfly 10 timing issue ?

[islpe]

I am currently migrating Jboss-4.2.1 to Wildfly-10.0.0, and I have what I think is a timing issue during startup. I have a number of  what Jboss called a 'lightweight' services, i.e each deployment described with a .xml file describing what this deployment contains. One of these deployment is to initiate a queue during startup using the jndi name java:/ConnectionFactory. Sometimes the startup of this deployment go well and sometimes it does not. In the situations where the startup fails it is always with this exception javax.naming.NameNotFoundException: ConnectionFactory -- service jboss.naming.context.java.ConnectionFactory. So sometimes the jndi name exists and some time it does not. I have dumped the contents of various namespaces before initiating the queue, and this is perfectly aligned with the exception. When the startup fails, the name java:/ConnectionFactory does not exist. When the startup succeeds the name java;/ConnectionFactory exists.

.

Because of the multithreaded deployment used by Wildfly I used to think that my deployment tried to access ActiveMQ before it was ready, i.e before 'Server is now live' written in the log, but this is not the case .I have seen situations where the startup fails after 'Server is now live' is written to the log. In the situation where the startup has failed I can undeploy the deployemt. If I deploy it afterwards the deployment starts nicely up and showing the existence of java:/ConnectionFactory.

I have looked through the forums for similar behaviour but no one seem to match my problem. I start Wildfly using the file standalone-full.xml.

Does anyone have an idea of what causes this behaviour and does anyone have a suggestion for a fix ?

Regards

Lasse Petersen    .   

[jbertram]

The simplest way to resolve this issue is likely just to retry the JNDI lookup when you hit a failure.  Insert a small delay (e.g. 200ms) between retries and after X number of retries then throw an exception.  That should deal with the timing issue.

[islpe]

The workaround you suggest has also been in my mind, but I will not use this yet. I had hoped for another answer for this problem To me it seems odd that WildFly's ActiveMQ component in the application log writes 'Server is now live' and then later on in the log it writes 'trying to deploy a queue' or 'resource adaptor started'. I will dig deeper into the problem, and if I find an answer, I will post it here.  

[ctomc]

WildFly uses new core architecture where whole boot process is multi threaded.

So unless you have proper dependencies defined between components you could see problem like you see now.

How do you do jndi lookup? by using InitialContext.lookup? or by injection?

if you would do something like

@Resource(mappedName="java:/ConnectionFactory")

private ConnectionFactory factory;

it should work. as server knows about relationship and it will wait till service is ready to inject it.

[jbertram]

To me it seems odd that WildFly's ActiveMQ component in the application log writes 'Server is now live' and then later on in the log it writes 'trying to deploy a queue' or 'resource adaptor started'...

This is the expected behavior, I believe.  You should establish proper dependencies like Tomaz suggested or implement a retry as I suggested if you're not using a component which support resource injection.

[islpe]

I do have a dependency between some components so they need to start in the right sequence.

Being an older application it uses InitialContext. I will try the use of @Resource