January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBAS-3216) PooledInvokerProxy.getPooledConnection() is not threadsafe

by Ola Bini (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3216?page=comments#action_12351642 ] Ola Bini commented on JBAS-3216: -------------------------------- Sorry, I looked at the branch for 4.0.4.GA and compared with 4.0.5.GA and didn't see any change. I should've looked at the tags, of course. > PooledInvokerProxy.getPooledConnection() is not threadsafe > ---------------------------------------------------------- > > Key: JBAS-3216 > URL: http://jira.jboss.com/jira/browse/JBAS-3216 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remoting > Affects Versions: JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1 > Reporter: Anders Welen > Assigned To: Scott M Stark > Fix For: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.CR1 > > > Code from 4.0.3SP1 > ================= > protected ClientSocket getPooledConnection() > { > ClientSocket socket = null; > while (pool.size() > 0) > { > socket = (ClientSocket)pool.removeFirst(); > try > { > // Test to see if socket is alive by send ACK message > final byte ACK = 1; > socket.out.writeByte(ACK); > socket.out.flush(); > socket.in.readByte(); > return socket; > } > catch (Exception ex) > { > try > { > socket.socket.close(); > } > catch (Exception ignored) {} > } > } > return null; > } > =========================== > Should be changed to: > protected ClientSocket getPooledConnection() > { > ClientSocket socket = null; > synchronized (pool) { > while (pool.size() > 0) > { > socket = (ClientSocket)pool.removeFirst(); > try > { > // Test to see if socket is alive by send ACK message > final byte ACK = 1; > socket.out.writeByte(ACK); > socket.out.flush(); > socket.in.readByte(); > return socket; > } > catch (Exception ex) > { > try > { > socket.socket.close(); > } > catch (Exception ignored) {} > } > } > } > return null; > } > =========================== > ....or perhaps better: > protected ClientSocket getPooledConnection() > { > ClientSocket socket = null; > while (pool.size() > 0) > { > try { > socket = (ClientSocket)pool.removeFirst(); > } > catch (java.util.NoSuchElementException nsee) > { > return null; > } > try > { > // Test to see if socket is alive by send ACK message > final byte ACK = 1; > socket.out.writeByte(ACK); > socket.out.flush(); > socket.in.readByte(); > return socket; > } > catch (Exception ex) > { > try > { > socket.socket.close(); > } > catch (Exception ignored) {} > } > } > return null; > } -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-3216) PooledInvokerProxy.getPooledConnection() is not threadsafe

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3216?page=comments#action_12351640 ] Dimitris Andreadis commented on JBAS-3216: ------------------------------------------ According to this case it has been fixed for jboss 4.0.5.GA, so what is the problem? > PooledInvokerProxy.getPooledConnection() is not threadsafe > ---------------------------------------------------------- > > Key: JBAS-3216 > URL: http://jira.jboss.com/jira/browse/JBAS-3216 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remoting > Affects Versions: JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1 > Reporter: Anders Welen > Assigned To: Scott M Stark > Fix For: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.CR1 > > > Code from 4.0.3SP1 > ================= > protected ClientSocket getPooledConnection() > { > ClientSocket socket = null; > while (pool.size() > 0) > { > socket = (ClientSocket)pool.removeFirst(); > try > { > // Test to see if socket is alive by send ACK message > final byte ACK = 1; > socket.out.writeByte(ACK); > socket.out.flush(); > socket.in.readByte(); > return socket; > } > catch (Exception ex) > { > try > { > socket.socket.close(); > } > catch (Exception ignored) {} > } > } > return null; > } > =========================== > Should be changed to: > protected ClientSocket getPooledConnection() > { > ClientSocket socket = null; > synchronized (pool) { > while (pool.size() > 0) > { > socket = (ClientSocket)pool.removeFirst(); > try > { > // Test to see if socket is alive by send ACK message > final byte ACK = 1; > socket.out.writeByte(ACK); > socket.out.flush(); > socket.in.readByte(); > return socket; > } > catch (Exception ex) > { > try > { > socket.socket.close(); > } > catch (Exception ignored) {} > } > } > } > return null; > } > =========================== > ....or perhaps better: > protected ClientSocket getPooledConnection() > { > ClientSocket socket = null; > while (pool.size() > 0) > { > try { > socket = (ClientSocket)pool.removeFirst(); > } > catch (java.util.NoSuchElementException nsee) > { > return null; > } > try > { > // Test to see if socket is alive by send ACK message > final byte ACK = 1; > socket.out.writeByte(ACK); > socket.out.flush(); > socket.in.readByte(); > return socket; > } > catch (Exception ex) > { > try > { > socket.socket.close(); > } > catch (Exception ignored) {} > } > } > return null; > } -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-827) Memory leak with simple example code

by Johan Parent (JIRA)

Memory leak with simple example code ------------------------------------ Key: JBPM-827 URL: http://jira.jboss.com/jira/browse/JBPM-827 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.3, jBPM 3.1.2 Environment: java 1.4.2 Reporter: Johan Parent Assigned To: Tom Baeyens The Websale example wrapped in a simple for-loop in standalone app. reveals what resembles a memory leak. Performance degrades severely as the JVM starts to do some expensive gc after 4000 iterations. At that time the JVM consume more than 274Mb of ram (JVM not started with special -X options!) Problem occurs with HSQLDB as well as Sybase db. The code to reproduce this problem has been posted here http://www.jboss.com/index.html?module=bb&op=viewtopic&t=99440 Iter. ms (per iter.) -------------------------- 3993 291 3994 280 3995 281 3996 300 3997 270 3998 301 3999 290 4000 281 4001 2093 4002 270 4003 310 4004 271 4005 280 4006 291 4007 300 4008 280 4009 2183 4010 281 4011 290 4012 281 4013 270 4014 311 4015 280 4016 280 4017 2083 4018 301 4019 270 4020 290 4021 281 4022 300 4023 281 4024 280 4025 2113 -- 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

19 years, 3 months

3
9
0 / 0

[JBoss JIRA] Assigned: (JBAOP-268) Get jdk15.dynamic tests working with generated advisors

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-268?page=all ] Kabir Khan reassigned JBAOP-268: -------------------------------- Assignee: Flavia Rainone * Hopefully the jvm bug has been fixed > Get jdk15.dynamic tests working with generated advisors > ------------------------------------------------------- > > Key: JBAOP-268 > URL: http://jira.jboss.com/jira/browse/JBAOP-268 > Project: JBoss AOP > Issue Type: Sub-task > Reporter: Kabir Khan > Assigned To: Flavia Rainone * > Fix For: 2.0.0.alpha3 > > > Some classloader stuff is going on with these tests causing them not to work with generated advisors - they are currently set up to use ClassicInstrumentor -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-3216) PooledInvokerProxy.getPooledConnection() is not threadsafe

by Ola Bini (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3216?page=comments#action_12351637 ] Ola Bini commented on JBAS-3216: -------------------------------- This bug is not fixed in any of the versions abovementioned. It is a serious showstopper and need to be fixed for the next version. This bug should be reopened. > PooledInvokerProxy.getPooledConnection() is not threadsafe > ---------------------------------------------------------- > > Key: JBAS-3216 > URL: http://jira.jboss.com/jira/browse/JBAS-3216 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remoting > Affects Versions: JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1 > Reporter: Anders Welen > Assigned To: Scott M Stark > Fix For: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.CR1 > > > Code from 4.0.3SP1 > ================= > protected ClientSocket getPooledConnection() > { > ClientSocket socket = null; > while (pool.size() > 0) > { > socket = (ClientSocket)pool.removeFirst(); > try > { > // Test to see if socket is alive by send ACK message > final byte ACK = 1; > socket.out.writeByte(ACK); > socket.out.flush(); > socket.in.readByte(); > return socket; > } > catch (Exception ex) > { > try > { > socket.socket.close(); > } > catch (Exception ignored) {} > } > } > return null; > } > =========================== > Should be changed to: > protected ClientSocket getPooledConnection() > { > ClientSocket socket = null; > synchronized (pool) { > while (pool.size() > 0) > { > socket = (ClientSocket)pool.removeFirst(); > try > { > // Test to see if socket is alive by send ACK message > final byte ACK = 1; > socket.out.writeByte(ACK); > socket.out.flush(); > socket.in.readByte(); > return socket; > } > catch (Exception ex) > { > try > { > socket.socket.close(); > } > catch (Exception ignored) {} > } > } > } > return null; > } > =========================== > ....or perhaps better: > protected ClientSocket getPooledConnection() > { > ClientSocket socket = null; > while (pool.size() > 0) > { > try { > socket = (ClientSocket)pool.removeFirst(); > } > catch (java.util.NoSuchElementException nsee) > { > return null; > } > try > { > // Test to see if socket is alive by send ACK message > final byte ACK = 1; > socket.out.writeByte(ACK); > socket.out.flush(); > socket.in.readByte(); > return socket; > } > catch (Exception ex) > { > try > { > socket.socket.close(); > } > catch (Exception ignored) {} > } > } > return null; > } -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4014) timer persistence in afterCompletion

by Alexey Loubyansky (JIRA)

timer persistence in afterCompletion ------------------------------------ Key: JBAS-4014 URL: http://jira.jboss.com/jira/browse/JBAS-4014 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Scheduling/Timers Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1, JBossAS-4.0.5.SP1 org.jboss.ejb.txtimer.TimerImpl does some persistence work in afterCompletion. All the work should be done in the beforeCompletion and it's the responsibility of the db to rollback in case it should. -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-948) Patch to add return value (boolean) to removeChild*() and removeNode*() methods

by Elias Ross (JIRA)

Patch to add return value (boolean) to removeChild*() and removeNode*() methods ------------------------------------------------------------------------------- Key: JBCACHE-948 URL: http://jira.jboss.com/jira/browse/JBCACHE-948 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2, 2.0.0.ALPHA1 Reporter: Elias Ross Assigned To: Manik Surtani Attachments: remove.patch It is useful to know if a node was actually removed or not. Having a return value adds a bit of usefulness. A boolean return value is consistent with Collections.remove(). In any case, it's a small but potentially useful API change which I suggest for 2.0 release. For example, in CacheImpl, there was no way to detect removal failures: void _remove() ... try { _remove(tx, tmp, create_undo_ops, true, eviction); } catch (Exception e) { log.error("failure removing node " + tmp); } The patch includes the changes and additional tests. -- 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

19 years, 3 months

2
2
0 / 0

[JBoss JIRA] Assigned: (JBAS-1537) When Tomcat error handler is invoked, JBossGenericPrincipal is returned instead of custom principal

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1537?page=all ] Scott M Stark reassigned JBAS-1537: ----------------------------------- Assignee: Scott M Stark (was: Anil Saldhana) > When Tomcat error handler is invoked, JBossGenericPrincipal is returned instead of custom principal > --------------------------------------------------------------------------------------------------- > > Key: JBAS-1537 > URL: http://jira.jboss.com/jira/browse/JBAS-1537 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Affects Versions: JBossAS-4.0.1 Final > Environment: linux i386, jdk 1.4.2_07 > Reporter: Rick Wong > Assigned To: Scott M Stark > Fix For: JBossAS-4.2.0.CR1 > > > Hi, > I followed the instruction in the Wiki to set up a custom principal > http://www.jboss.org/wiki/Wiki.jsp?page=UsingCustomPrincpalsWith > Normally, this works perfectly such that the call to > request.getUserPrincipal() > returns my custom principal type. However, if a JSP error page is invoked either by the default error handler in the web.xml, or by the JSP declaration, a different Principal object is returned. > A call to request.getUserPrincipal() in the error handler results in an object of type > org.jboss.web.tomcat.security.JBossGenericPrincipal > Is this by design? Shouldn't it also return my custom attribute? > Thanks, > -- > Rick -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBFORUMS-118) preview and submitting show different signature

by Ronald van Kuijk (JIRA)

preview and submitting show different signature ----------------------------------------------- Key: JBFORUMS-118 URL: http://jira.jboss.com/jira/browse/JBFORUMS-118 Project: JBoss Forums Issue Type: Bug Environment: JBoss LABS as it is in production on august 12th 2006, Client: both FF and IE Reporter: Ronald van Kuijk Assigned To: Sohil Shah Priority: Minor I changed my signature to make it so that it shows that I'm not a JBoss employee, nor in anyway affiliated. This new signature shows up on the preview of the message, but after posting it, it is my old signature. I tried logging out and in again, clearing cookies etc... but to no avail. -- 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

19 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-384) ListenerManagerFileUnitTest does nothing (from what I can see) :-)

by Tom Fennelly (JIRA)

ListenerManagerFileUnitTest does nothing (from what I can see) :-) ------------------------------------------------------------------ Key: JBESB-384 URL: http://jira.jboss.com/jira/browse/JBESB-384 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.0 CR2 Reporter: Tom Fennelly Assigned To: Mark Little Priority: Minor Fix For: 4.0 Maintenance Pack 1 The "testOne" method simply returns - first line is "if(true) return;" -- 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

19 years, 3 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2007