[JBoss JIRA] Created: (JBAS-5095) Race condition between connection.close() and transaction.rollback() causes connection leak
by Adrian Brock (JIRA)
Race condition between connection.close() and transaction.rollback() causes connection leak
-------------------------------------------------------------------------------------------
Key: JBAS-5095
URL: http://jira.jboss.com/jira/browse/JBAS-5095
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.2.2.GA
Reporter: Adrian Brock
Assigned To: Adrian Brock
Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.3.GA
There is a race condition between the connection.close() and an asynchronous transaction completion
(e.g. transaction timeout) that can lead to a leaked connection permit with eventual pool exhaustion
when using track-connection-by-tx (i.e. all local resources).
The problem is caused in the TxConnectionManager where the unregister assoication and the afterCompletion
are not synchronized with each other. Both can see the connection as ready to return to the pool
(one removes the handle, the other the synchronization at about the same time so they both check
the same state) and both do it.
The InternalManagedConnectionPool does not check for duplicate returns and uses an ArrayList to
store connections (for the MRU behaviour). So the connection ends up in the pool twice
This eventually causes problems like the leaked permit.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Created: (JGRP-817) MethodCall: match between formal parameters and actual arguments fails if an argument is a subtype of a parameter
by Bela Ban (JIRA)
MethodCall: match between formal parameters and actual arguments fails if an argument is a subtype of a parameter
-----------------------------------------------------------------------------------------------------------------
Key: JGRP-817
URL: https://jira.jboss.org/jira/browse/JGRP-817
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.6.4, 2.7
If we have class Foo with method:
public class Foo {
public void bar(Object a, String b) {}
}
then MethodCall fails if we invoke:
dispatcher.callRemoteMethods(null, "bar", new Object[] {"hello", "world"}, new Class[]{String.class,String.class}, ...);
because the first formal parameter of foo() is an Object and the arg a String, and we do an equals() on the 2 classes.
Solution: use Class.isAssignableFrom(Class)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Created: (JBAS-5925) startup problem on AIX
by Aleksandar Kostadinov (JIRA)
startup problem on AIX
----------------------
Key: JBAS-5925
URL: https://jira.jboss.org/jira/browse/JBAS-5925
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: JBossAS-5.0.0.CR2
Environment: AIX with IPv6 enabled
Reporter: Aleksandar Kostadinov
When starting server on AIX it throws exceptions:
java.net.BindException: The socket name is not available on this system.
The issue is some confusion with IPv6, because -Djava.net.preferIPv4Stack=true fixes the issue.
Currently run.sh adds the option by default for linux. But I wonder if we shouldn't have it by default for all OSes and optionally turned off by a command line switch or environment variable. Another solution is to just add "AIX" to the have_it_by_default list.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Created: (JBAS-5910) Point out the -b flag in the docs
by Dimitris Andreadis (JIRA)
Point out the -b flag in the docs
---------------------------------
Key: JBAS-5910
URL: https://jira.jboss.org/jira/browse/JBAS-5910
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Docs/Administration and Configuration Guide, Docs/Installation and Getting Started Guide
Reporter: Dimitris Andreadis
Assignee: Samson Kittoli
Fix For: JBossAS-5.0.0.CR2
>From Tim:
"I just had a user, new to JBoss have a problem connecting to a remote jboss server.
It turns out it was a classic problem, he hadn't specified the -b parameter when starting the AS so it was just binding to localhost and could not be contacted.
This kind of thing is obvious to old time users, but not to newbs.
I looked through the AS and EAP doco trying to find an explanation or note "remember to set -b if you want your server to be contactable", but could find only a tiny explanation of -b in the getting started guide, sec 2.3.3:
"-b, --host=<host or ip> Bind address for all JBoss services". It mentions nothing about what the default is, and that it needs to be specified.
Might I suggest a bit more doco here?"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Created: (JBRULES-1758) Compiled Rule Would Not Execute with Array of Objects in Java Expressions
by Ming Jin (JIRA)
Compiled Rule Would Not Execute with Array of Objects in Java Expressions
-------------------------------------------------------------------------
Key: JBRULES-1758
URL: https://jira.jboss.org/jira/browse/JBRULES-1758
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 5.0.0.M1
Environment: Java
Reporter: Ming Jin
Assignee: Mark Proctor
Attachments: testdrools.zip
The compilation is fine for a rule containing the following statement:
eval($fact.stayHasDaysOfWeek("1,2,3", false, (String[][]){{"2008-04-01", "2008-04-10"}})),
But would cause the following exception during execution:
org.drools.RuntimeDroolsException: org.drools.base.mvel.MVELEvalExpression@1ad98ef : org.mvel.PropertyAccessException: unable to resolve property: $fact.stayHasDaysOfWeek("1,2,3", false, (String[][]){{"2008-04-01", "2008-04-10"}})
....
Will upload the test project to demonstrate this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Commented: (JBAS-1984) HttpNamingContextFactory unable to reconnect
by Adrian Brock (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-1984?page=com.atlassian.jira.plug... ]
Adrian Brock commented on JBAS-1984:
------------------------------------
It would probably be worthwhile adding to this "FeatureRequest"
a couple of extra naming properties such as:
jnp.retry.count = number of times to retry on an I/O Exception (default 0)
jnp.retry.delay = number of seconds to wait between retries (default about 5-10 seconds?)
Then this would really be a supported transparent reconnect mechanism.
> HttpNamingContextFactory unable to reconnect
> --------------------------------------------
>
> Key: JBAS-1984
> URL: https://jira.jboss.org/jira/browse/JBAS-1984
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: JBossAS-3.2.7 Final
> Environment: XP
> Reporter: Bernd Eckenfels
> Assignee: Emanuel Muckenhuber
> Fix For: JBossAS-5.0.1.CR1
>
>
> Unlike the normal JNP/RMI Connection the HttpNamingContextFactory created Context does not recover from a application server shutdown. If I repeat lookups, the exception after the application server is available again looks like this:
> ex: javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1363)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:575)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:568)
> at net.eckenfels.JNDITest.main(JNDITest.java:72)
> Caused by: javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:250)
> at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1348)
> ... 3 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:224)
> ... 4 more
> Caused by: java.net.UnknownHostException: http: http
> at java.net.InetAddress.getAllByName0(InetAddress.java:1128)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1098)
> at java.net.InetAddress.getAllByName(InetAddress.java:1061)
> at java.net.InetAddress.getByName(InetAddress.java:958)
> at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:61)
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:220)
> ... 4 more
> Note the Unknown Host Exception, which looks pretty much like a destroyed or miss-parsed URL. Since the connection work with the same InitialContext instance before, the setup is correct:
> p.put("java.naming.factory.initial", "org.jboss.naming.HttpNamingContextFactory");
> p.put("java.naming.provider.url", "http://127.0.0.1:8080/invoker/JNDIFactory");
> p.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
> p.put("jnp.disableDiscovery", "true");
> Context rootCtx = (Context)new InitialContext(p);
> while(true)
> {
> try
> {
> // rootCtx = new InitialContext(p);
> Context jmxCtx = (Context)rootCtx.lookup("/jmx/rmi");
> l = jmxCtx.list("");
> while(l.hasMore())
> {
> System.out.println(" - " + l.next());
> }
> } catch (Throwable t) {
> System.out.println("ex: " + t); t.printStackTrace(System.out);
> }
> try{Thread.sleep(10000);}catch(Throwable t) { }
> }
> This sample code works if i uncomment the re-creation of the InitialContext, however this is neighter needed by the JNP/RMI Version nor does the exception look like sane handling.
> The client is using jbossall-client.jar and jdk 1.5_04. Jboss 3.2.7 is running (unmodified default profile) on 1.5, too. Problem exists with 3.2.6, too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Commented: (JBAS-1984) HttpNamingContextFactory unable to reconnect
by Dimitris Andreadis (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-1984?page=com.atlassian.jira.plug... ]
Dimitris Andreadis commented on JBAS-1984:
------------------------------------------
Adrian, thanks for jumping in.
> HttpNamingContextFactory unable to reconnect
> --------------------------------------------
>
> Key: JBAS-1984
> URL: https://jira.jboss.org/jira/browse/JBAS-1984
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: JBossAS-3.2.7 Final
> Environment: XP
> Reporter: Bernd Eckenfels
> Assignee: Emanuel Muckenhuber
> Fix For: JBossAS-5.0.1.CR1
>
>
> Unlike the normal JNP/RMI Connection the HttpNamingContextFactory created Context does not recover from a application server shutdown. If I repeat lookups, the exception after the application server is available again looks like this:
> ex: javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1363)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:575)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:568)
> at net.eckenfels.JNDITest.main(JNDITest.java:72)
> Caused by: javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:250)
> at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1348)
> ... 3 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:224)
> ... 4 more
> Caused by: java.net.UnknownHostException: http: http
> at java.net.InetAddress.getAllByName0(InetAddress.java:1128)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1098)
> at java.net.InetAddress.getAllByName(InetAddress.java:1061)
> at java.net.InetAddress.getByName(InetAddress.java:958)
> at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:61)
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:220)
> ... 4 more
> Note the Unknown Host Exception, which looks pretty much like a destroyed or miss-parsed URL. Since the connection work with the same InitialContext instance before, the setup is correct:
> p.put("java.naming.factory.initial", "org.jboss.naming.HttpNamingContextFactory");
> p.put("java.naming.provider.url", "http://127.0.0.1:8080/invoker/JNDIFactory");
> p.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
> p.put("jnp.disableDiscovery", "true");
> Context rootCtx = (Context)new InitialContext(p);
> while(true)
> {
> try
> {
> // rootCtx = new InitialContext(p);
> Context jmxCtx = (Context)rootCtx.lookup("/jmx/rmi");
> l = jmxCtx.list("");
> while(l.hasMore())
> {
> System.out.println(" - " + l.next());
> }
> } catch (Throwable t) {
> System.out.println("ex: " + t); t.printStackTrace(System.out);
> }
> try{Thread.sleep(10000);}catch(Throwable t) { }
> }
> This sample code works if i uncomment the re-creation of the InitialContext, however this is neighter needed by the JNP/RMI Version nor does the exception look like sane handling.
> The client is using jbossall-client.jar and jdk 1.5_04. Jboss 3.2.7 is running (unmodified default profile) on 1.5, too. Problem exists with 3.2.6, too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Commented: (JBAS-1984) HttpNamingContextFactory unable to reconnect
by Adrian Brock (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-1984?page=com.atlassian.jira.plug... ]
Adrian Brock commented on JBAS-1984:
------------------------------------
I think this should be a feature request since you should always recreate the InitialContext
after an "IOException".
It only works for jnp by "accident". The "stub" lookup on the bootstrap port 1099 is lazy
and cached for jnp. When we get an I/O exception we clear the cache .
This is actually because otherwise the stale cached version would mean you could never recreate the
InitialContext due to the way the RMI protocol works (not because it is intended to provide
a semi-transparent failover mechanism).
For HTTP the "stub" lookup is not lazy. If it tries to reconnect, it will use the jnp bootstrap mechanism
which will fail since it has the wrong information in the provider url (and is the wrong protocol anyway).
Incidently, for HTTP we don't need to clear the cache because the protocol is stateless unlike RMI.
So there are two possible "fixes":
1) A way to tell NamingContext not to flush the cache for HTTP when an I/O Exception occurs
so we can take advantage of the stateless behaviour.
2) A way to override the (re)connect logic in NamingContext.getServer(host, port, refEnv)
so the HTTPNamingContextFactory can tell it to use the http mechanism.
The second solution would also have the advantage that it could be lazy about retrieving
the stub, i.e. HTTPNamingContextFactory could just do
// Parse/check the env and prefix
return new NamingContext(env, prefix, null);
like the jnp version.
In practice, some element of both solutions would be desirable.
> HttpNamingContextFactory unable to reconnect
> --------------------------------------------
>
> Key: JBAS-1984
> URL: https://jira.jboss.org/jira/browse/JBAS-1984
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: JBossAS-3.2.7 Final
> Environment: XP
> Reporter: Bernd Eckenfels
> Assignee: Emanuel Muckenhuber
> Fix For: JBossAS-5.0.1.CR1
>
>
> Unlike the normal JNP/RMI Connection the HttpNamingContextFactory created Context does not recover from a application server shutdown. If I repeat lookups, the exception after the application server is available again looks like this:
> ex: javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1363)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:575)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:568)
> at net.eckenfels.JNDITest.main(JNDITest.java:72)
> Caused by: javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:250)
> at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1348)
> ... 3 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:224)
> ... 4 more
> Caused by: java.net.UnknownHostException: http: http
> at java.net.InetAddress.getAllByName0(InetAddress.java:1128)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1098)
> at java.net.InetAddress.getAllByName(InetAddress.java:1061)
> at java.net.InetAddress.getByName(InetAddress.java:958)
> at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:61)
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:220)
> ... 4 more
> Note the Unknown Host Exception, which looks pretty much like a destroyed or miss-parsed URL. Since the connection work with the same InitialContext instance before, the setup is correct:
> p.put("java.naming.factory.initial", "org.jboss.naming.HttpNamingContextFactory");
> p.put("java.naming.provider.url", "http://127.0.0.1:8080/invoker/JNDIFactory");
> p.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
> p.put("jnp.disableDiscovery", "true");
> Context rootCtx = (Context)new InitialContext(p);
> while(true)
> {
> try
> {
> // rootCtx = new InitialContext(p);
> Context jmxCtx = (Context)rootCtx.lookup("/jmx/rmi");
> l = jmxCtx.list("");
> while(l.hasMore())
> {
> System.out.println(" - " + l.next());
> }
> } catch (Throwable t) {
> System.out.println("ex: " + t); t.printStackTrace(System.out);
> }
> try{Thread.sleep(10000);}catch(Throwable t) { }
> }
> This sample code works if i uncomment the re-creation of the InitialContext, however this is neighter needed by the JNP/RMI Version nor does the exception look like sane handling.
> The client is using jbossall-client.jar and jdk 1.5_04. Jboss 3.2.7 is running (unmodified default profile) on 1.5, too. Problem exists with 3.2.6, too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months