[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
[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
[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
[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
[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
[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