December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1249) Replication exceptions should not propagate to cache caller

by Manik Surtani (JIRA)

Replication exceptions should not propagate to cache caller ----------------------------------------------------------- Key: JBCACHE-1249 URL: http://jira.jboss.com/jira/browse/JBCACHE-1249 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR2 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA -- 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

18 years, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (GPD-138) error dialogue appears on task panel of properties for task node

by Ross McDonald (JIRA)

error dialogue appears on task panel of properties for task node ---------------------------------------------------------------- Key: GPD-138 URL: http://jira.jboss.com/jira/browse/GPD-138 Project: JBoss jBPM GPD Issue Type: Bug Components: jpdl Affects Versions: jBPM JPDL Designer 3.1.0.beta1 Environment: os x macbok pro, eclipse 3.3.0 Reporter: Ross McDonald Assigned To: Koen Aers Priority: Minor Hi, when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details : Reason: 0 'An error has occurred. See error log for more details. 0 On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no error. -- 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

18 years, 6 months

2
16
0 / 0

[JBoss JIRA] Created: (GPD-168) feature not recognized

by Joachim Neubert (JIRA)

feature not recognized ---------------------- Key: GPD-168 URL: http://jira.jboss.com/jira/browse/GPD-168 Project: JBoss jBPM GPD Issue Type: Bug Affects Versions: jBPM JPDL Designer 3.1.0.GA Environment: Java 1.5, Eclipse Europa, JBoss Tools 2.0 beta3, Seam 2.0 beta1 Reporter: Joachim Neubert Assigned To: Koen Aers After deleting the CR feature and plugin directories and installing the GA as described in readme.html, the org.jbpm.gd.jpdl.feature is not recognized by Eclipse. -- 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

18 years, 6 months

3
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-911) manage remote dependency injection

by William DeCoste (JIRA)

manage remote dependency injection ---------------------------------- Key: EJBTHREE-911 URL: http://jira.jboss.com/jira/browse/EJBTHREE-911 Project: EJB 3.0 Issue Type: Feature Request Reporter: William DeCoste Assigned To: William DeCoste There are two EJBs, A and B, which are deployed in different JBoss instances. A reference of the EJB B should be injected in the EJB A. But if during deployment of A, the instance of the EJB B is not running, the injection can not succeed. It would be great feature, that the injection in A can succeed, after the EJB B is deployed. -- 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

18 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-876) Up-port to trunk of EJBTHREE-875

by Carlo de Wolf (JIRA)

Up-port to trunk of EJBTHREE-875 -------------------------------- Key: EJBTHREE-876 URL: http://jira.jboss.com/jira/browse/EJBTHREE-876 Project: EJB 3.0 Issue Type: Sub-task Reporter: Carlo de Wolf Fix For: EJB 3.0 RC11 - FD -- 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

18 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1253) Unneeded copying of data in Notifier

by Bela Ban (JIRA)

Unneeded copying of data in Notifier ------------------------------------ Key: JBCACHE-1253 URL: http://jira.jboss.com/jira/browse/JBCACHE-1253 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR2 Reporter: Bela Ban Assigned To: Manik Surtani All Notifier.notifyXXX() methods are written like this: public void notifyNodeActivated(Fqn fqn, boolean pre, Map data, InvocationContext ctx) { boolean originLocal = ctx.isOriginLocal(); Map dataCopy = copy(data); // <===== COPY ! Transaction tx = ctx.getTransaction(); List<ListenerInvocation> listeners = listenerInvocations.get(NodeActivated.class); if (listeners != null && listeners.size() > 0) { InvocationContext backup = resetInvocationContext(ctx); // ... bla bla } } The data (hashmap) is copied regardless of whether there are actually any listeners, this leads to poor performance. I saw this as hotspot #1 in my perf tests with JBossCache in JProfiler. FIX: copy only if there are any listeners -- 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

18 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-843) MicroSocketClientInvoker can miscount number of active sockets

by Ron Sigal (JIRA)

MicroSocketClientInvoker can miscount number of active sockets -------------------------------------------------------------- Key: JBREM-843 URL: http://jira.jboss.com/jira/browse/JBREM-843 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto), 2.2.2.SP2 org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains (1) a pool of available sockets, and (2) a counter, usedPooled, of the number of sockets currently in use. Because the sequence of (1) checking for a free socket in the pool, and (2) creating a new socket if the pool is empty, is not in a synchronized block, it is possible to create more sockets than the maximum pool size. In particular, the following sequence of events can produce "extra" sockets: 1. Thread 1 sees that the pool is empty, 2. Thread 2 returns a socket to the pool, and 3. Thread 1 creates a new socket. It would be possible to synchronize events 1 and 3, but it's probably undesirable since the process of getting a socket from the pool can be time consuming if the "socket.check_connection" flag is set to true. Therefore, MicroSocketClientInvoker tolerates the possibility of creating "extra" sockets. However, it never puts more than the configured maximum number of sockets in the pool. That is, if the pool is full (i.e., size == maxPoolSize), then, when an invocation completes, the socket used for that invocation will be discarded instead of being added to the pool. The problem is that the usedPooled counter is incremented every time a socket is created and decremented every time a socket is returned to the pool, but is is *not* decremented when a socket is discarded. Suppose maxPoolSize is 100, If 101 sockets are created, 100 sockets are returned to the pool, and 1 socket is discarded, then the resulting value of usedPooled will be 1 instead of 0. It appears, then, that there is 1 socket in use, so MicroSocketClientInvoker will create no more than 99 additional sockets (excluding the race described above). So, there is a leak, not of sockets, but of "slots" for sockets. Eventually, it could become impossible to create new sockets. -- 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

18 years, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-889) If an exception occurs during invocation, usedPooled is not decremented, thus leading into eventual remoting failures

by Hasan Ceylan (JIRA)

If an exception occurs during invocation, usedPooled is not decremented, thus leading into eventual remoting failures ---------------------------------------------------------------------------------------------------------------------- Key: JBREM-889 URL: http://jira.jboss.com/jira/browse/JBREM-889 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.2.SP1 Environment: Should for all environments Reporter: Hasan Ceylan Hello, I guess this goes into Ron's area. Back in 2004 we had had a similar issue. :) In MicroSocketClientInvoker.transport(), having obtained a socket, if an exception occurs during the invocation, the code that decrements usedPooled never gets called thus inflating overtime. Eventually reaches 50, the hard limit which in turn, makes clients unable to obtain a socket from pool or create a new one. I guess, a try, finally block is needed starting right after successful socket acquired, till where you decrement the usedPooled (marked with // Put socket back in pool for reuse). This will make sure the usedPooled is decremented. I searched the JIRA and also found similar bug reports which I believe all should be related. Regards, Hasan Ceylan -- 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

18 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (GPD-191) ESB Service Node

by Koen Aers (JIRA)

ESB Service Node ---------------- Key: GPD-191 URL: http://jira.jboss.com/jira/browse/GPD-191 Project: JBoss jBPM GPD Issue Type: Feature Request Components: jpdl Reporter: Koen Aers Assigned To: Koen Aers Fix For: jBPM jPDL Designer 3.1.2 ESB Service Node A new icon on the tool palette that would inject the following JPDL syntax into my process definition: <node name="Calculate Discount"> <action name="esbAction" class="org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler"> <esbCategoryName>BPM_Orchestration4</esbCategoryName> <esbServiceName>DiscountService</esbServiceName> <jbpmToEsbVars> <mapping jbpm="entireCustomerAsObject" esb="customer" /> <mapping jbpm="entireOrderAsObject" esb="orderHeader" /> <mapping jbpm="entireOrderAsXML" esb="BODY_CONTENT" /> </jbpmToEsbVars> <returnVars> <mapping jbpm="entireOrderAsObject" esb="order" /> </returnVars> </action> <transition name="" to="Review Discount"></transition> </node> And provide a property sheet that allows me to specify the service name, category and the mapping of process variables to esb message parts. -- 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

18 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5048) Lookup of resource bound via ExternalContext using a CompondName results in serialization of org.jnp.interfaces.FastNamingProperties

by Mike Clark (JIRA)

Lookup of resource bound via ExternalContext using a CompondName results in serialization of org.jnp.interfaces.FastNamingProperties ------------------------------------------------------------------------------------------------------------------------------------ Key: JBAS-5048 URL: http://jira.jboss.com/jira/browse/JBAS-5048 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Naming Affects Versions: JBossAS-4.0.5.GA Reporter: Mike Clark Assigned To: Scott M Stark When a user registers resources using the org.jboss.naming.ExternalContext, they can only successfully lookup resources on the remote JNDI system if they first lookup the Context registered in the ExternalContext and then look up resources on the returned Context. Looking up the full name results in the use of the org.jnp.interfaces.FastNamingProperties class which is not generally available on the remote JNDI implementation. So, for example, a user might register "external/foreign_jndi" using the ExternalContext. Looking up resource, a/b/c as follows works: Context initialContext = new InitialContext(); Context remoteContext = (Context) initialContext.lookup("external/foreign_jndi"); Object obj = remoteContext.lookup("a/b/c"); while, the more direct Context initialContext = new InitialContext(); Object obj = initialContext.lookup("external/foreign_jndi/a/b/c"); results in a "java.lang.ClassNotFoundException: org.jnp.interfaces.FastNamingProperties" exception on the remote JNDI system. It appears to occur because the FastNamingProperties class is used in the construction of the CompoundName in the org.jnp.interfaces.NamingParser. So, in the first case, the parsing of "a/b/c" is handled by the foreign JNDI system, while in the latter, the CompoundName containing the FastNamingProperties is passed to the foreign JNDI system. -- 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

18 years, 6 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 December 2007