[sreenathac]

Hi Scott,

Earlier in AS5.1.0 it used to take 5 -7 min to start and deploy my application, 20 seconds is for loading initilization. In wildFly 8.2.0 the data loading is not even started. It is waiting without any error till it gets connection timeout. It is a same case even we have increased the time out.(The trace log is copied above).

To start the the process we are invoking the using InitialContext.

final InitialContext initialContext = new InitialContext();

  final AppDataProvider bean = (AppDataProvider) initialContext

  .lookup("java:app/project-ejb/AppDataProviderBean");

  resultList=bean.loadAllList();

We are not getting any exception when it calls lookup method and the server get stucked when executing the last line(bean.loadAllList()). FYI AppDataProveder is and interface annotated with @Local and AppDataProviderBean is a stateless bean which implements AppDataProvider.

For your reference below is my data source configuration.

<datasource jta="true" jndi-name="java:jboss/datasources/testDatasource" pool-name="TestDS" enabled="true" use-ccm="true">

                    <connection-url>jdbc:oracle:thin:@192.155.11.105:1521:orcl</connection-url>

                    <driver>oracle</driver>

                    <pool>

                        <min-pool-size>1</min-pool-size>

                        <max-pool-size>50</max-pool-size>

                        <prefill>true</prefill>

                    </pool>

                    <security>

                        <user-name>testuser</user-name>

                        <password>testpassword</password>

                    </security>

                    <validation>

                        <validate-on-match>true</validate-on-match>

                        <background-validation>false</background-validation>

                    </validation>

                    <timeout>

                        <set-tx-query-timeout>false</set-tx-query-timeout>

                        <blocking-timeout-millis>30000</blocking-timeout-millis>

                        <idle-timeout-minutes>30000</idle-timeout-minutes>

                        <query-timeout>30000</query-timeout>

                        <use-try-lock>30000</use-try-lock>

                        <allocation-retry>30000</allocation-retry>

                        <allocation-retry-wait-millis>30000</allocation-retry-wait-millis>

                    </timeout>

                    <statement>

                        <share-prepared-statements>false</share-prepared-statements>

                    </statement>

                </datasource>

Note: Here we are accessing the database which is located in Virtual Machine(Not local host).

Please let us know if you have any thoughts on this.

[smarlow]

Did you resolve your related issue listed at https://developer.jboss.org/message/938360?

We are not getting any exception when it calls lookup method and the server get stucked when executing the last line(bean.loadAllList()). FYI AppDataProveder is and interface annotated with @Local and AppDataProviderBean is a stateless bean which implements AppDataProvider.

How do you know that the server is stuck when executing the last line?  Did you examine that application server threads via a thread dump?  Exactly which line of code is the application server executing?

[sreenathac]

Hi scott,

I have verified using debug pointer, While executing bean.loadAllList() it is not performing any operation. Moreover I have written only one logger message in bean.loadAllList() which is not displaying.

While executing

final AppDataProvider bean = (AppDataProvider) initialContext

  .lookup("java:app/project-ejb/AppDataProviderBean");

While executing the above code I am getting the bean object, it is not throwing any Exception. But when I am calling a method in the bean no operation is performing

i.e bean.loadAllList()

[smarlow]

It doesn't sound like a "transaction timeout" problem then.  It sounds like you need more application changes to continue your migration.  I don't know why your call to bean.loadAllList() didn't enter the loadAllList method.

Have you searched for "migrating seam to wildfly"?  I tried that in google and saw a few hits (https://docs.jboss.org/author/display/WFLY8/Seam+2+Booking+EAR+Migration+of+Binaries+-+Step+by+Step).

[sreenathac]

Hi Scott,

Before starting with my project upgrade, we migrated a small application successfully. For this issue we are suspecting that we are calling this method from a bean which has @Startup annotation. The flow will be

1) Application Scoop bean with annotation @Startup-> A plain java class which has all static methods-> calling the bean method to load the data as per above message.

I am suspecting that there might be a problem in wildfly while invoking the Stateless EJB from @Startup bean i.e while deploying the application.

We have skipped the code which is causing the issue and resolved few other issues faced while deploying, able to deploy the application successfully.

After deployment is successful, while loading the logiin page it is calling the method bean.loadAllList() though I have soome other issues while loading the login page I am able to see the appropriate loggers and sql queries which shows the above method is calling.

[smarlow]

What happens if you try using WildFly 10.0.0.Beta2?

[sreenathac]

I will try to deploy on 10.0.0 Beta and let you know the result

[sreenathac]

Hi Scott,

In my application we are using hibernate 3.6.3, I observed that WildFly 10.0.0 Beta will not support Hibernate 3.x. when I am deploying my application I am getting the Hibernate Exception.

we are suspecting that there might be an issue in WildFly 8.2.0 related to the above scenario. We are trying for alternative ways to achieve this, please let us know if you have any?

[jaikiran]

Sreenath Reddy wrote:

Hi Scott,

Before starting with my project upgrade, we migrated a small application successfully. For this issue we are suspecting that we are calling this method from a bean which has @Startup annotation. The flow will be

1) Application Scoop bean with annotation @Startup-> A plain java class which has all static methods-> calling the bean method to load the data as per above message.

I am suspecting that there might be a problem in wildfly while invoking the Stateless EJB from @Startup bean i.e while deploying the application.

We have skipped the code which is causing the issue and resolved few other issues faced while deploying, able to deploy the application successfully.

After deployment is successful, while loading the logiin page it is calling the method bean.loadAllList() though I have soome other issues while loading the login page I am able to see the appropriate loggers and sql queries which shows the above method is calling.

Have you taken thread dumps to see where exactly it hangs? From what you have been describing, I suspect the transaction semantics of a @Startup @Singleton EJB and the connection isolation level on the connection of your Datasource are coming into play.The EJB 3.1 spec section 4.8.3 is as follows:

4.8.3 Transaction Semantics of Initialization and Destruction

PostConstruct and PreDestroy methods of Singletons with container-managed transactions are transac-

tional. From the bean developer’s view there is no client of a PostConstruct or PreDestroy method.

A PostConstruct or PreDestroy method of a Singleton with container-managed transactions has transac-

tion attribute REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED (Required , RequiresNew, or

NotSupported if the deployment descriptor is used to specify the transaction attribute).

Note that the container must start a new transaction if the REQUIRED (Required) transaction

attribute is used. This guarantees, for example, that the transactional behavior of the PostConstruct

method is the same regardless of whether it is initialized eagerly at container startup time or as a side

effect of a first client invocation on the Singleton. The REQUIRED transaction attribute value is

allowed so that specification of a transaction attribute for the Singleton PostConstruct/PreDestroy

methods can be defaulted.

You will have to investigate how the application is dealing with the connections and the transaction, in this context.

[sreenathac]

Resolved this issue, I am using Seam 2.3.1 and Hibernate 3.6.3. This issue was resolved after upgrading my hibernate to 4.0.1