December 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1776) Proper Handling of JBossConnection.setExceptionListener() when being called on a bad connection

by Howard Gao (JIRA)

Proper Handling of JBossConnection.setExceptionListener() when being called on a bad connection ----------------------------------------------------------------------------------------------- Key: JBMESSAGING-1776 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1776 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.6.GA, 1.4.5.GA, 1.4.0.SP3.CP09 Reporter: Howard Gao Assignee: Howard Gao Fix For: 1.4.0.SP3.CP10, 1.4.6.GA.SP1, 1.4.7.GA If the user call Connection.setExceptioListener() on a bad connection, JBM doesn't give any information about it. Therefore the exception listener will never get notified of the bad state. -- 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, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBJCA-240) Allow multi @Connector if it has deployment description

by Jeff Zhang (JIRA)

Allow multi @Connector if it has deployment description -------------------------------------------------------- Key: JBJCA-240 URL: https://jira.jboss.org/jira/browse/JBJCA-240 Project: JBoss JCA Issue Type: Bug Components: Deployer Reporter: Jeff Zhang Assignee: Jeff Zhang Fix For: 1.0.0.Alpha7 now it disallow multi @Connector define in rar. method processConnector in Annotations.java if (values.size() == 1) { ... } else throw new DeployException("More than one @Connector defined"); but in spec: (18.4) If more than one JavaBean is annotated with the Connector annotation, the application server must use the JavaBean class specified in the deployment descriptor through the resourceadapter-class element. It is an error to provide a resource adapter module with more than one JavaBean class annotated with the Connector annotation and not providing a deployment descriptor. -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1115) TCPPING cookie read error on load

by Sanjay Prasad (JIRA)

TCPPING cookie read error on load --------------------------------- Key: JGRP-1115 URL: https://jira.jboss.org/jira/browse/JGRP-1115 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP4 Environment: red hat linux 2.6.9-78.0.8.EL 64 bit, java 1.5, jboss 4.2.2 Reporter: Sanjay Prasad Assignee: Bela Ban BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks does not use readFully to read the cookie and so during high load, runs into cookie related error. Changing the line to readFully fixes the issue. 499 500 // read the cookie first 501 in.read(input_cookie, 0, input_cookie.length); 502 if(!matchCookie(input_cookie)) 503 throw new SocketException("ConnectionTable.Connection .readPeerAddress(): cookie sent by " + 504 client_peer_addr + " does n ot match own cookie; terminating connection"); 505 // then read the version 506 version=in.readShort(); 507 doSend when it fails, removes the connection in the exception block and so the second try in _send always fails with the error "2nd attempt to send data failed too" as the connection is already closed. void doSend(byte[] data, int offset, int length) throws Exception { try { // we're using 'double-writes', sending the buffer to the destination in 2 pieces. this would // ensure that, if the peer closed the connection while we were idle, we would get an exception. // this won't happen if we use a single write (see Stevens, ch. 5.13). if(out != null) { out.writeInt(length); // write the length of the data buffer first Util.doubleWrite(data, offset, length, out); out.flush(); // may not be very efficient (but safe) } } catch(Exception ex) { remove(peer_addr); throw ex; } } private void _send(byte[] data, int offset, int length) { synchronized(send_mutex) { try { doSend(data, offset, length); updateLastAccessed(); } catch(IOException io_ex) { if(log.isWarnEnabled()) log.warn("peer closed connection, trying to re-send msg"); try { doSend(data, offset, length); updateLastAccessed(); } catch(IOException io_ex2) { if(log.isErrorEnabled()) log.error("2nd attempt to send data failed 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, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-7559) Unable to add RMINotificationListener for "JMImplementation:type=MBeanServerDelegate" from different VM

by martin walla (JIRA)

Unable to add RMINotificationListener for "JMImplementation:type=MBeanServerDelegate" from different VM ------------------------------------------------------------------------------------------------------- Key: JBAS-7559 URL: https://jira.jboss.org/jira/browse/JBAS-7559 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-5.1.0.GA Environment: Windows XP, JBoss 5.1.0.GA, JDK 1.6.0_16 Reporter: martin walla Assignee: Dimitris Andreadis I listen for the Notifications (JMX.mbean.registered, JMX.mbean.unregistered) of the MBeanServer "JMImplementation:type=MBeanServerDelegate". I want to do that inside the JBoss VM and also from a different VM (e.g. a JUnit Test case). I add a RMINotificationListener via the RMIAdaptor. If i do it within the JBoss VM everything is fine and works OK. If i do it from a different VM the RMINotificationListener class can't be found. org.jboss.invocation.JBossLazyUnmarshallingException: getArguments failed at org.jboss.invocation.MarshalledInvocation.getArguments(MarshalledInvocation.java:513) at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:233) Caused by: java.lang.ClassNotFoundException: org.jboss.jmx.adaptor.rmi.RMINotificationListener at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at org.jboss.invocation.MarshalledValueInputStream.resolveProxyClass(MarshalledValueInputStream.java:159) at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1531) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1493) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:91) at org.jboss.invocation.MarshalledInvocation.getArguments(MarshalledInvocation.java:509) The reason is: In case of calling addNotificationListener() from a different VM the invocation is a MarshalledInvocation. In the invoke() method of the org.jboss.jmx.connector.invoker.InvokerAdaptorService there is a call to Object[] args = invocation.getArguments(); In the getArguments() it comes to the unmarshalling of the arguments (one is the RMINotificationListener). Therefore it is tried to load the argument classes via the Thread's contextClassLoader. In the InvokerAdaptorService few statements before the getArguments() call there is a call to getClassLoaderFor(ObjectName name) of the MBeanServerImpl // Obtain the ClassLoader associated with the MBean deployment newCL = server.getClassLoaderFor(objectName); The InvokerAdaptorService then sets the Thread's contextClassLoader. if (newCL != null && newCL != oldCL) SecurityActions.setContextClassLoader(newCL); In the method getClassLoaderFor() the SystemClassLoader is returned for the "JMImplementation:type=MBeanServerDelegate". public ClassLoader getClassLoaderFor(ObjectName name) throws InstanceNotFoundException { MBeanEntry entry = registry.get(name); checkMBeanPermission(entry.getResourceClassName(), null, name, "getClassLoaderFor"); ClassLoader cl = entry.getClassLoader(); if (cl == null) cl = entry.getResourceInstance().getClass().getClassLoader(); if (cl == null) cl = ClassLoader.getSystemClassLoader(); return cl; } The SystemClassLoader didn't the see RMINotificationListener. Possible solution: If null or the Thread's contextClassLoader would be returned instead of the SystemClassLoader then the InvokerAdaptorService didn't modify the Thread's contextClassLoader and the RMINotificationListener is found (and it works OK). -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBEE-17) Resolve trunk build issues

by Shelly McGowan (JIRA)

Resolve trunk build issues -------------------------- Key: JBEE-17 URL: https://jira.jboss.org/jira/browse/JBEE-17 Project: JBoss JavaEE APIs Issue Type: Bug Reporter: Shelly McGowan Assignee: Shelly McGowan Fix For: 6.0.0.Alpha1 http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-Javaee/12/ -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1117) BasicConnectionTable.Connection: buffer only increases, never shrinks

by Bela Ban (JIRA)

BasicConnectionTable.Connection: buffer only increases, never shrinks --------------------------------------------------------------------- Key: JGRP-1117 URL: https://jira.jboss.org/jira/browse/JGRP-1117 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.4.8, 2.6.14, 2.8 The byte[] buffer in run() is increased with message size. However, when we accidentally read a wrong length field, e.g. as the result of someone connecting and sending crap, the buffer is way too big. SOLUTION: create the buffer anew for every message. [Email from Jimmy Wilson] One of the issues appears to lead to a 1.5GB byte buffer inside ConnectionTable that is never reclaimed (it's the latest issue discussed on the case). We have heap dumps showing that this byte buffer grew to this size. Dennis's comments from the ticket: > The buffer appears to be the re-sizeable one from org.jgroups.blocks.BasicConnectionTable.Connection.run(). > The contents of the buffer is: > JGroups version (2.4.5) > IP Address (172.20.30.15:7900) > list of: length (53) > org.jgroups.Message (TCPPING for null-Data channel) > The full data JGroups sends on a TCP connection is: > Cookie ('b','e','l','a') > JGroups version > IP address > list of: length, Message > Connection.readPeerAddress is responsible for reading the cookie, JGroups version, and IP address. Connection.run then runs a loop that > reads a length and Message and processes them. > The buffer size is 1,650,814,049 => 0x62656c61 => "bela". > So it looks like Connection.readPeerAddress is not pulling anything > off the socket input stream before Connection.run is called, so run > reads the cookie, thinks it's the buffer length to use, and starts > reading until the buffer is full. Dennis and I've spent some time looking at how this might happen, but it doesn't appear that the code is the problem. The server side doesn't appear to be the problem because the 'bela' cookie/array is only received once (upon the reception of a connection), yet, for the code path to be what it appears, that array would have to be in the input stream twice. The client side doesn't appear to be the problem as connections are created inside a synchronized block, and each connection is only initialized once (therefore the 'bela' cookie/array is only sent once). Dennis currently suspects a JVM issue with threads, but we're just guessing at this point. Do you have any thoughts on what might be happening here (there are other, more recent, private comments on the case)? -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWEB-156) Tomcat Startup fails during authentication

by Stelios Koussouris (JIRA)

Tomcat Startup fails during authentication ------------------------------------------ Key: JBWEB-156 URL: https://jira.jboss.org/jira/browse/JBWEB-156 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Tomcat Reporter: Stelios Koussouris Assignee: Jean-Frederic Clere Tomcat Startup with JNDI Realm defined fails Exception in tomcat.log 14 2009/10/08-11:03:52 Oct 8, 2009 11:03:52 AM org.apache.catalina.realm.JNDIRealm open 15 2009/10/08-11:03:52 WARNING: Exception performing authentication 16 2009/10/08-11:03:52 javax.naming.CommunicationException: hostname.example.com:22389 [Root exception is java.net.ConnectException: Connection refused] Full descriptiopn http://pastebin.gsslab.fab.redhat.com/mypaste/vcCe/ Needs to be fixed also in tc5.5.5.23 brew -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMETA-239) Upgrade to latest jboss-metadata-common

by jaikiran pai (JIRA)

Upgrade to latest jboss-metadata-common --------------------------------------- Key: JBMETA-239 URL: https://jira.jboss.org/jira/browse/JBMETA-239 Project: JBoss Metadata Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Components: client Reporter: jaikiran pai Assignee: jaikiran pai Upgrade to jboss-metadata-common 2.0.0-alpha-10 -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMETA-240) Upgrade to latest jboss-metadata-common

by jaikiran pai (JIRA)

Upgrade to latest jboss-metadata-common --------------------------------------- Key: JBMETA-240 URL: https://jira.jboss.org/jira/browse/JBMETA-240 Project: JBoss Metadata Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Components: ear Reporter: jaikiran pai Assignee: jaikiran pai Upgrade to jboss-metadata-common 2.0.0-alpha-10 -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Closed: (EJBTHREE-191) servlet initialization happens before EJB startup

by Carlo de Wolf (JIRA)

[ https://jira.jboss.org/jira/browse/EJBTHREE-191?page=com.atlassian.jira.p... ] Carlo de Wolf closed EJBTHREE-191. ---------------------------------- Fix Version/s: (was: Branch_4_2) Resolution: Out of Date > servlet initialization happens before EJB startup > ------------------------------------------------- > > Key: EJBTHREE-191 > URL: https://jira.jboss.org/jira/browse/EJBTHREE-191 > Project: EJB 3.0 > Issue Type: Bug > Reporter: Bill Burke > -- 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, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2009