[EJB 3.0 Development] - Timeout Calling EJB from Remote Location
by Tim Eakins
Tim Eakins [http://community.jboss.org/people/teakins] created the discussion
"Timeout Calling EJB from Remote Location"
To view the discussion, visit: http://community.jboss.org/message/535036#535036
--------------------------------------------------------------
I'm really stuck on this one. I can successfully run my webstart swing application which makes EJB 3.0 calls to my JBoss 5.1.0 server when I'm on the local network, but not when I'm outside. In that case, I get timeouts and "Could not obtain connection to any of these urls: pf.servername.org:1099". Full exception is toward the bottom. Firewall is off. All appropriate ports are forwarded.
Even more confusing, I'm able to see the website that I've put the .jnlp and jarfiles on for downloading. That works fine, jsp debugging output comes through on server.
The logical layout is as follows
Server Router Outside Domain External Client
192.168.1.7 192.168.1.1 pf.servername.org Any.IP (DOESN'T WORK!!)
Local
Client
192.168.1.100 (THIS WORKS! Even when using pf.servername.org for all references!)
At first I suspected blocked ports, but everything seems to be fine. My server is as follows. As mentioned above, I can run with all server references using pf.servername.org and it all works as expected.
On the server
Running my JBoss application 'pf', everything starts up without warnings or exceptions. I see the EJBs no problem.
Startup command:
./run.sh -b 192.168.1.7 -c pf
Ports Forwarded
# Name Start Port End Port Server IP Address
7 PF 8080 8080 192.168.1.7
8 HTTPS 443 443 192.168.1.7
9 RMI 8083 8083 192.168.1.7
10 PFIC 1090 1099 192.168.1.7
11 PFRMIC 4444 4444 192.168.1.7
12 PFEJB 3873 3873 192.168.1.7
13 bisocket 4457 4457 192.168.1.7
Made sure no firewall
# /etc/init.d/iptables stop
iptables: Flushing firewall rules: OK
iptables: Setting chains to policy ACCEPT: filter OK
iptables: Unloading modules: OK
hosts is simple, but has reference
# cat /etc/hosts
# hostname viper added to /etc/hosts by anaconda
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 viper
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 viper
192.168.1.7 viper
Any of the online port checkers say that 1099 is open.
On the external client:
After swing jar has downloaded via webstart and runs, output in console
Logger.java:239: Failed to connect to pf.servername.org:1099
javax.naming.CommunicationException: Failed to connect to server pf.servername.org/68.xxx.45.160:1099 Root exception is
javax.naming.ServiceUnavailableException: Failed to connect to server pf.servername.org/68.xxx.45.160:1099 Root exception is
java.net.ConnectException: Connection timed out: connect
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:335)
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1734)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:693)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
at javax.naming.InitialContext.lookup(Unknown Source)
...
Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server pf.servername.org/68.xxx.45.160:1099 Root exception is
java.net.ConnectException: Connection timed out: connect
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:305)
... 17 more
Caused by: java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectTo(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.netSocket.connect(Unknown Source)
...
?:?: Unable to connect to remote. error=Could not obtain connection to any of these urls: pf.servername.org:1099
So I'm really confused. jars download, application comes up, but no EJB calls work.
I should point out that even though my client works locally, I do get these "errors" that don't prohibit functionality.
PFPersister is an EJB
Logger.java:228: Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler@1526e3: Current invocation "public abstract java.lang.Object pfcommon.ejb.library.persist.PFPersisterInterface.queryForObject(java.lang.String,java.util.Map)" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler@1526e3
Logger.java:228: Received invocation request to method pfcommon.ejb.library.persist.PFPersisterInterfaceRemote: pfcommon.ejb.library.persist.PFPersisterInterface.queryForObject(java.lang.String,java.util.Map); using hash: 4728166201795524950
Logger.java:228: SocketClientInvoker[4276fd, socket://192.168.1.7:3873] connecting
Logger.java:228: SocketClientInvoker[4276fd, socket://192.168.1.7:3873] connected
Logger.java:228: removed SocketClientInvoker[4276fd, socket://192.168.1.7:3873] from registry
Searching groups for this hasn't yet shown what the problem is here.
I've also tried putting @RemoteBinding entries as well with no luck.
Any help, thoughts much appreciated!
Thanks,
Tim
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535036#535036]
Start a new discussion in EJB 3.0 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - On demand resolution
by Thomas Diesler
Thomas Diesler [http://community.jboss.org/people/thomas.diesler%40jboss.com] replied to the discussion
"On demand resolution"
To view the discussion, visit: http://community.jboss.org/message/535023#535023
--------------------------------------------------------------
I changed the reset logic such that it resets to the state that it was before the resolve attept.
Instead of always reset to "DESCRIBE".
// Advance the bundles to stage CLASSLOADER and check at the end
if (advanceBundlesToClassloader(resolvableBundles) == false)
{
resetBundleDeploymentStates(resolvableBundles);
allResolved = false;
}
private void resetBundleDeploymentStates(List<OSGiBundleState> resolvableBundles)
{
for (OSGiBundleState bundleState: resolvableBundles)
{
DeploymentUnit unit = bundleState.getDeploymentUnit();
StateTuple stateTuple = unit.removeAttachment(StateTuple.class);
if (stateTuple != null)
{
stateTuple.reset(unit);
}
}
}
The DeploymentMetaData is not available in 6.0.0.M2, so I had to refactor that out into a separate deployer that does a noop in M2.
With the recent change we also get spurious WARN messages
22:54:34,034 WARN [BaseDelegateLoader] Not getting package org.osgi.service.log from policy that has no classLoader: LazyFilteredDelegateLoader@191eb90{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)1004a1a filter=<EVERYTHING>}
22:54:34,040 WARN [BaseDelegateLoader] Not getting package org.osgi.service.log from policy that has no classLoader: LazyFilteredDelegateLoader@191eb90{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)1004a1a filter=<EVERYTHING>}
22:54:34,065 INFO [FrameworkEventsPluginImpl] Service REGISTERED: Service{id=8,classes=[org.osgi.service.log.LogService]}
22:54:34,069 INFO [FrameworkEventsPluginImpl] Service REGISTERED: Service{id=9,classes=[org.osgi.service.log.LogReaderService]}
22:54:34,075 WARN [BaseDelegateLoader] Not getting package org.osgi.util.tracker from policy that has no classLoader: LazyFilteredDelegateLoader@191eb90{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)1004a1a filter=<EVERYTHING>}
22:54:34,076 WARN [BaseDelegateLoader] Not getting package org.osgi.util.tracker from policy that has no classLoader: LazyFilteredDelegateLoader@191eb90{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)1004a1a filter=<EVERYTHING>}
22:54:34,076 WARN [BaseDelegateLoader] Not getting resource org/osgi/util/tracker/ServiceTrackerCustomizer.class from policy that has no classLoader: LazyFilteredDelegateLoader@191eb90{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)1004a1a filter=<EVERYTHING>}
22:54:34,111 WARN [BaseDelegateLoader] Not getting resource org/osgi/util/tracker/ServiceTracker$AllTracked.class from policy that has no classLoader: LazyFilteredDelegateLoader@191eb90{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)1004a1a filter=<EVERYTHING>}
22:54:34,112 WARN [BaseDelegateLoader] Not getting resource org/osgi/util/tracker/ServiceTracker$Tracked.class from policy that has no classLoader: LazyFilteredDelegateLoader@191eb90{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)1004a1a filter=<EVERYTHING>}
22:54:34,114 WARN [BaseDelegateLoader] Not getting resource org/osgi/util/tracker/AbstractTracked.class from policy that has no classLoader: LazyFilteredDelegateLoader@191eb90{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)1004a1a filter=<EVERYTHING>
which is because the DynamicClassLoaderPolicyFactory does not create a policy. Not sure how this is suposed to work.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535023#535023]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month
Re: [jboss-dev-forums] [JBoss Transactions Development] - beanifying the config
by Jonathan Halliday
Jonathan Halliday [http://community.jboss.org/people/jhalliday] replied to the discussion
"beanifying the config"
To view the discussion, visit: http://community.jboss.org/message/534922#534922
--------------------------------------------------------------
The problem of dynamically changing property values at point of use is actually orthogonal to the one of holding the same property in multiple forms. Each is a synchronization problem, but of different forms.
For any property, not just strings/classes, there is the question: when does a change to the value in its canonical home (the EnvironmentBean) take effect in things that use that property? The answer right now is: probably never. The value is read from the bean at startup (or first use) and effectively cached at the point of use, usually in a static variable. Therefore subsequent updates modify the bean but not the point of use and are thus ineffective.
For properties that have dual representation e.g. String vs. Class, there is the question of how/when updates to one of those representations affect the other. That's a much more limited problem. Right now for example, putting a getName/getInstance pair on an EnvironmentBean would just require figuring out the synchronization between them and moving the classloading code from point of use to inside the bean. But it won't address the problem that the point of use is calling either getName or getInstance once only and not rechecking either for later updates.
Initially I'm just looking to reduce the duplication of classloading code and allow for bean injection by putting Class getters/setters on the beans. After that I'll worry about the dynamic change at point of use problem. The former has a generic solution for all String/Class cases, whereas the latter will require individual examination of each point of use. In many cases I think we can probably move from static variable to instance variable and static initializer block to constructor for initializing it from the bean. But it's related to lifetime and use of the object constructed.
For example, the useAlternativeOrdering applies in comparison of records, so changing that will cause really screwy behaviour if it leads to comparing a set of records some of which were created before and some after the change. In another case the port number for a listener would require restarting that listener to take effect, which a) is not feasible at present and b) would have consequence for any clients trying to connect if they don't see the update at the same time. That's a distributed form of a problem that also exists inside the same VM - how to coordinate updates where there is more than one point of use for the same property and they need to be consistent. Should a component restart be triggered from the bean, requiring the bean to have knowledge of its users, or do we need an event registration mechanism so the listener can get a callback and restart itself when the bean property is updated? As you an see there are some common themes, each property's case is different and will need thinking about.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/534922#534922]
Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month