November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-822) Avoid deadlock when Connector shuts down while callback client invoker is in handleConnect()

by Ron Sigal (JIRA)

Avoid deadlock when Connector shuts down while callback client invoker is in handleConnect() -------------------------------------------------------------------------------------------- Key: JBREM-822 URL: http://jira.jboss.com/jira/browse/JBREM-822 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Clebert Suconic has experienced a deadlock while shutting down the Application Server. The thread dump shows that the AS has called Connector.stop(), which leads to a call to the synchronized method org.jboss.remoting.MicroRemoteClientInvoker.disconnect() on the callback org.jboss.remoting.transport.bisocket.BisocketClientInvoker. However, all this happens at the same time that a callback handler is being installed, which leads to a call to the synchronized method MicroRemoteClientInvoker.connect() on *the same* callback BisocketClientInvoker. The BisocketClientInvoker is in BisocketClientInvoker.handleConnect(), where it is waiting (with, in the case of JBossMessaging, a timeout of 0) to get a control socket. As a result, MicroRemoteClientInvoker.disconnect() is blocked and cannot execute. This situation needs careful study. Do MicroRemoteClientInvoker.connect() and MicroRemoteClientInvoker.disconnect() need to be fully synchronized? -- 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

16 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-807) Fix failing org.jboss.test.remoting.transport.<transport>.shutdown tests

by Ron Sigal (JIRA)

Fix failing org.jboss.test.remoting.transport.<transport>.shutdown tests ------------------------------------------------------------------------ Key: JBREM-807 URL: http://jira.jboss.com/jira/browse/JBREM-807 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) The org.jboss.test.remoting.transport.<transport>.shutdown tests were created for JBREM-674, to verify that no non-terminating non-daemon threads could prevent Remoting clients and servers from shutting down. Some of these tests have been failing. -- 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

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-821) JBoss Remoting fails under load

by Ovidiu Feodorov (JIRA)

JBoss Remoting fails under load ------------------------------- Key: JBREM-821 URL: http://jira.jboss.com/jira/browse/JBREM-821 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP1 Reporter: Ovidiu Feodorov Assigned To: Trustin Lee Priority: Blocker This is a duplicate of JBMESSAGING-1114 present here to remind Remoting people that Messaging has this urgent need. Phrasing belongs to Tim: JBoss Remoting fails with various different errors when under extreme load. To replicate this, set up two clustered server nodes, using a MySQL database. These can both be on the same machine, using ServiceBindingManager. On a second machine run Ovidiu's messkit toolki, first to send some messages: mess -stat send -size 10240 50000 And then to receive them back using 50 concurrent consumers: mess -stat -sessions 50 receive all You will notice that JBoss Remoting fails with errors: I believe this is due to remoting incorrectly thinking a connection has failed and shutting down the connection. Perhaps due to the load, the ping does not get through in time to refresh the lease? I would like a remoting solution that *does not ping* from server to client - for us this is unnecessary. It also seems remoting is continually timing out and recreating connections - this could also be a source of error. How do we configure remoting so it does not do this? -- 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

16 years, 11 months

3
14
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-211) Support .. notion in vfs paths

by Adrian Brock (JIRA)

Support .. notion in vfs paths ------------------------------ Key: JBMICROCONT-211 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-211 Project: JBoss MicroContainer Issue Type: Feature Request Components: VFS Affects Versions: JBossMC-2.0.0.Beta4 Reporter: Adrian Brock If a VFS path contains a .. it should be possible to invoke getParent() to navigate the path in AbstractVirtualFileHandler's structuredFindChild() and simpleFindChild() currently the PathTokenizer will report an error if the path contains a . or .. It should still through an error if it "goes off the top" of the VFS context. i.e. you try to a .. on a virtual file handler with no parent. -- 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

16 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1074) Support the use of Integer, Float, Short and Byte in accumulate functions

by Geoffrey De Smet (JIRA)

Support the use of Integer, Float, Short and Byte in accumulate functions ------------------------------------------------------------------------- Key: JBRULES-1074 URL: http://jira.jboss.com/jira/browse/JBRULES-1074 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.GA Reporter: Geoffrey De Smet Assigned To: Edson Tirelli Priority: Minor Fix For: 4.0.1 Currently, even if everything is an Integer (or int's) a value still gets supplied as a Long. -- 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

16 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1775) Let a user define multiple display-name for a portlet-instance in the admin portlet

by Thomas Heute (JIRA)

Let a user define multiple display-name for a portlet-instance in the admin portlet ----------------------------------------------------------------------------------- Key: JBPORTAL-1775 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1775 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Core Admin Reporter: Thomas Heute Assigned To: Wesley Hales Fix For: 2.6.3 Final When an administrator creates a new portlet-instance, he should be able to define (and edit) different display-names for a single instance. -- 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

16 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1165) Endless loop in PessimisticLockInterceptor

by Jacek Halat (JIRA)

Endless loop in PessimisticLockInterceptor ------------------------------------------ Key: JBCACHE-1165 URL: http://jira.jboss.com/jira/browse/JBCACHE-1165 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP4 Environment: Windows XP, Sun jdk150_06 Solaris 10 Reporter: Jacek Halat Assigned To: Manik Surtani When 2 Threads are simulatanous putting/removing values from this same node TreeCache hang's up and goes into endless loop. Main loop looks like: for (int x = 0; x < 1000; x++) { tm.begin(); System.out.println("R" + Thread.currentThread().getName()); //inside transaction cache.remove("/a"); System.out.println("AR" + Thread.currentThread().getName()); tm.commit(); //outside transaction System.out.println("P" + Thread.currentThread().getName()); cache.put("/a/b/c/d", "text"+x,"b"); System.out.println("AP" + Thread.currentThread().getName()); } -- 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

16 years, 11 months

5
19
0 / 0

[JBoss JIRA] Created: (JBAS-4997) Package StatefulPassivationActivationUnitTestCase with its own HAPartition

by Brian Stansberry (JIRA)

Package StatefulPassivationActivationUnitTestCase with its own HAPartition -------------------------------------------------------------------------- Key: JBAS-4997 URL: http://jira.jboss.com/jira/browse/JBAS-4997 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Test Suite Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor This test does thousands of invocations from a single thread. This makes it prone to timeout if nagling or JGroups message bundling are enabled on the HAPartition channel, since the single thread doesn't generate enough *concurrent* load to trigger prompt message transmission. We should deploy the test with a partition with its own channel so we don't have to factor this test into whether or not we want nagling/bundling on the standard channel. -- 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

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-853) Partial StringProperty replacement in ejb 3 container

by Roland R?z (JIRA)

Partial StringProperty replacement in ejb 3 container ----------------------------------------------------- Key: EJBTHREE-853 URL: http://jira.jboss.com/jira/browse/EJBTHREE-853 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC9 - FD Reporter: Roland R?z I tried to change the messageSelector in an EJB 3.0 MDB in the ejb.jar.xml containing partial System Property references (aaa${xyz}bbb). Sadly this didn't work as with ejb 2.1. I think fully supporting system property replacement as with ejb 2.x in EJB 3.0 would be a nice feature. The method org.jboss.ejb3.metamodel.EjbJarDDObjectFactory.getValue(String name, String value) could be changed to { value = org.jboss.util.StringPropertyReplacer.replaceProperties(value); } I would suggest, to implement the string property replacement even better in the class org.jboss.metamodel.descriptor.DDObjectFactory.getValue() and remove the getValue method from JBossDDObjectFactory and EjbJarDDObjectFactory. The idea of using an MBean abstraction to replace system properties is fine but the nice syntax of the StringPropertyReplacer should be still supported (${v1,v2:default}). Returning always the replaced property is one possibility (currently it is not done this way) but probably a new method "getReplaced" would be less surprising. -- 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

16 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-375) Paralellize discovery phase

by Bela Ban (JIRA)

Paralellize discovery phase --------------------------- Key: JGRP-375 URL: http://jira.jboss.com/jira/browse/JGRP-375 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 With TCPPING, if we have 10 servers defined in the list, we sequentially send a GET_MBRS_REQ to each. However, if that server is not reachable, we will timeout out on the socket connect call. Also, DNS lookup might take some time, so we might time out if we cannot contact all servers. Example: servers 1 - 10. 1-9 are down or not reachable, plus we have a slow DNS, 10 is running. So before we get to 10, the discovery will timeout and we will become a singleton node. SOLUTION: use threads from the common (global) thread pool in JGroups to parallelize the sending of requests to all 10 servers. -- 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

16 years, 11 months

3
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007