We are upgrading JBOSS from (4.0.2) to latest Jboss (Wildfly 9.0.1) for our J2EE webApp. After upgrading we found that EJB calls are stop responding after 1 hour of load test.
Please note that the other areas of application is working fine where EJB is not used. The problem is only with remote EJB calls.
We have to restart Jboss to fix the issue.
Do we need to any configuration (threads/EJB pool) in Jboss (Wildfly 9.0.1)?
I'd just like to drop in and say that we're experiencing the same thing. What I recall reading is that this happens when the Wildfly has to wait to long to return an answer and suddenly the whole service becomes unresponsive.
We were running 8.2.0 Final and the only suggestion I could find was to upgrade. After performing an upgrade to 9.0.1 Final we're still seeing this. There was seemingly more people experiencing this but I have not been able to find any solution yet. The issues I found on the JBoss issue tracker on this have all been rejected and they're implying that it's more open for community discussion.
I have this lingering notion that toying around with timeouts might help though I haven't had time to try this yet.
P.S. I'm not privileged enough to simply comment which I would preferred.
Related
I am currently working on a web based application using Glassfish. Therefore I have to implement functionality, compile/package it (using maven), deploy the .war file on a glassfish server, test it and undeploy it again to start a new cycle.
My problem is, that Glassfish won't undeploy my .war file under Windows 7. Undeployment takes about 3 minutes and does not remove all deployed files in /glassfish/domains/myDomain/applications. It generates a .glassfishStaleFiles.
To deploy again, I first have to delete the content of /glassfish/domains/myDomain/applications entirely.
Obviously this takes too long and I need to do this many times a day while implementing.
BUT: It all works fine when using Ubuntu. Clean and fast undeployment and deployment.
Thanks in advance
This is a known issue with GlassFish, due to the way file handles are dealt with in Windows compared to Linux. If some process has a file open in Windows, then that will prevent deployment. There are lots of these edge cases in GlassFish many of which (perhaps all) have been fixed in Payara Server, which is derived from GlassFish. Payara Server is free, so I would recommend trying the latest version 4.1.2.174 to see if the issue is resolved there.
Here is an example of some of the fixes for these kinds of issues in Payara Server:
https://github.com/payara/Payara/pull/467
im trying to migrate JBoss AS7.1 to Wildfly 10, i just followed some threads and i came upon this AS7 to Wildfly 10 guide. Basically it just tells how to migrate server configuration as well as application configuration.
But the problem is, it says to execute ":migrate" function "/subsystem=jacorb:migrate" on jboss cli (Jboss AS7.1 because it says execute on legacy subsystem) but it always throws an error, see below
No handler for migrate at address
Anyone familiar in executing migrate on jboss cli please point me to the right direction
UPDATES
I opted to migrate to wildfly10 from jboss-as7.1 manually (labor intensive, hassle), maybe if i have time to investigate about this i could feedback it there but as of know i time is of the essence and i need to migrate immediately.
I migrating someone else's EJB 2.X app from jboss 3 to jboss 5 (and then maybe onto AS7).
When I do a test deployment of one of the EJBs I am getting this error
org.jboss.deployment.DeploymentException: Could not load class:
at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCEntityCommandMetaData.<init>
(JDBCEntityCommandMetaData.java:76)
at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCEntityMetaData.<init>
(JDBCEntityMetaData.java:954)...
Googling this stack trace doesn't give me any leads I can work on. As far as I can tell this means that the entity-command in conf/standardjbosscmp-jdbc.xml is wrong but I have no idea what it should be. Looking at the jboss 3 conf/standardjbosscmp-jdbc.xml file doesn't even have an entity-command listed so I assume "default" should be ok, no? I am using Oracle 11g, if that is meaningful and otherwise seem to have no db connection issues. The Oracle datasource seems to be created without problems. This is the very first error in the output. Any clues as to what i should look a to resolve this?
Are you sure you build everything against JBoss 5 libs? This could be a build problem...
I need to access EJBs deployed in JBoss AS 6, but I am using JBoss AS 7.1.1 Final, which dropped the JNP lookup.
Is it possible to do so, or do I need to downgrade to JBoss AS 6 (upgrading the other server is impossible)?
I've dug through the AS 7 forums and SO, but did not find any references for this..
Thanks in advance!
In general EJB remote communication between two different servers never works.
JBoss is especially known to have a total lack of attention for compatibility. Even a minor difference in version (a minor security update for instance) is already enough to break compatibility. I know for a fact that EJB remoting between JBoss AS 5 and 6 does not work, and I'm pretty sure it doesn't work between 6 and 7.
The root of the problem is that Java EE never specified how remote bean discovery should take place and what the requirements for the client exactly are (one exception is the application client container, which only works in Java SE and is so arcane that almost nobody uses it).
Most vendors use some kind of client jar, which in case of Jboss is nearly the entire server. Because it's nearly the entire server, you can't include it in another server as hundreds if not thousands of classes would clash.
A Jboss employee once started an experiment with an isolating class loader that would load these clients libs isolated from the main server, but as far as I know nobody ever got this to work.
I need to use some EJBs which are deployed on JBoss version 4.x from another EJB deployed on JBoss version 3.2.x. Is this possible?
I ask because I have a third party application which uses some strange bridge's to do that and don't know why (though I haven't try to do this on my own).
This is unfortunately not possible. One of the major drawbacks of remote EJBs is that there is nothing in the specification that guarantees or even suggests any kind of interoperability between different vendors or between different EJB versions from the same vendor.
In practice I found that at least with JBoss AS it never works. Even minor upgrades break binary compatibility completely. There have been some very hacky attempts with special class loaders that are only been given access to the client libs of the target JBoss AS, but this is very tricky to get right.
I guess this "strange bridge" you are talking about is using such a trick. Kudos to whoever build that bridge for getting this to work at all.
See this topic I started on the JBoss community forum for some more details: http://community.jboss.org/message/587180