[JBoss JIRA] Created: (JBAS-5923) Weak hash map usage in UnifiedInvokerHAProxy is not thread safe
by Galder Zamarreno (JIRA)
Weak hash map usage in UnifiedInvokerHAProxy is not thread safe
---------------------------------------------------------------
Key: JBAS-5923
URL: https://jira.jboss.org/jira/browse/JBAS-5923
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering, Transaction Manager (JBossTM)
Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.0.0.CR1
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
txFailoverAuthorizations weak hashmap that is now also used for
maintaining transaction stickyness was created as an unsynchronized
WeakHashMap and this was causing issues.
It was not enough to synchronise on the tpc (key of map) whenever
we manipulated it because two threads, trying to store different tpcs
could end up trying to resize the map and as a result, key value
pairs could easily dissapear from the hash map.
This is extremely confusing because we thought the disappearance
was due to garbage collection.
>From now on, we'll be using a Collections.synchronizedMap(new WeakHashMap());
instead. Thanks to Adrian for the help debugging this.
--
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
17 years, 3 months
[JBoss JIRA] Created: (HIBERNATE-104) useless stacktrace
by arne anka (JIRA)
useless stacktrace
------------------
Key: HIBERNATE-104
URL: https://jira.jboss.org/jira/browse/HIBERNATE-104
Project: Hibernate
Issue Type: Bug
Environment: jboss-4.2.2.GA, linux 32bit
Reporter: arne anka
Assignee: Steve Ebersole
when trying
entityManager.merge(myUser);
entityManager.flush();
i get a very long list of recurrent stacktraces. it boils down to two messages:
Caused by: org.hibernate.PropertyAccessException: IllegalArgumentException occurred calling getter of my.class.roleId
at org.hibernate.property.BasicPropertyAccessor$BasicGetter.get(BasicPropertyAccessor.java:171)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.getIdentifier(AbstractEntityTuplizer.java:183)
at org.hibernate.persister.entity.AbstractEntityPersister.getIdentifier(AbstractEntityPersister.java:3591)
at org.hibernate.persister.entity.AbstractEntityPersister.isTransient(AbstractEntityPersister.java:3307)
at org.hibernate.engine.ForeignKeys.isTransient(ForeignKeys.java:181)
at org.hibernate.engine.ForeignKeys.getEntityIdentifierIfNotUnsaved(ForeignKeys.java:218)
at org.hibernate.type.EntityType.getIdentifier(EntityType.java:397)
at org.hibernate.type.EntityType.replace(EntityType.java:253)
at org.hibernate.type.CollectionType.replaceElements(CollectionType.java:451)
at org.hibernate.type.Collecti
14:46:07,362 INFO [STDOUT] onType.replace(CollectionType.java:518)
at org.hibernate.type.TypeFactory.replace(TypeFactory.java:482)
at org.hibernate.event.def.DefaultMergeEventListener.copyValues(DefaultMergeEventListener.java:340)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsDetached(DefaultMergeEventListener.java:267)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:120)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:53)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:677)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:661)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:665)
at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:227)
... 74 more
and
Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException@661744
at sun.reflect.GeneratedMethodAccessor2266.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.hibernate.property.BasicPropertyAccessor$BasicGetter.get(BasicPropertyAccessor.java:145)
... 92 more
the property my.class.roleId is defined as Integer, setter and getter expect or return an Integer.
i can't see, what type hibernate expects as argument and i can't see in what type hibernate tries to cast.
- why does the stacktrace not mention the argument type hibernate expects?
- why does the stacktrace not mention in which type hibernate tries to cast?
with it's current level of null-information ist that _very_ long, confusing and time consuming stacktrace worse then useless.
i am completely unable to deduce any way to remedy a possible bug in my code or circumvent a possible bug in hibernate.
--
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
17 years, 3 months
[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
17 years, 3 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
17 years, 3 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
17 years, 3 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
17 years, 3 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
17 years, 3 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
17 years, 3 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
17 years, 3 months