March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBPM-395) SwimlaneInstance PooledActor assignment bug (not re-assignment issue)

by Britt Miner (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-395?page=comments#action_12355304 ] Britt Miner commented on JBPM-395: ---------------------------------- Definitely still an issue. > SwimlaneInstance PooledActor assignment bug (not re-assignment issue) > --------------------------------------------------------------------- > > Key: JBPM-395 > URL: http://jira.jboss.com/jira/browse/JBPM-395 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.0.1 > Environment: JDK 1.5, Postgresql, JBoss 4.0.2 > Reporter: Britt Miner > Assigned To: Tom Baeyens > > Initializing swimlaneInstances at process creation (or perhaps any time prior to creation of an associated task) will persist any configured actorId to the database, but configured PooledActors are not persisted. The AssignmentHandler functionality seems to work fine--the newly initialized swimlaneInstance has both actorId and pooledActors set correctly; however, the pooledActors will not be persisted. Allowing the swimlaneInstance to be initialized at creation of a related task does result in both actorId and pooledActors being properly persisted. > This issue is similar, though not identical, to http://jira.jboss.com/jira/browse/JBPM-375 and http://jira.jboss.com/jira/browse/JBPM-378 which are both related to swimlane assignment issues. > Why initialize swimlaneInstances at process creation? So that swimlane assignments can be made based on the initiator of the process (responsibilities broken down by regional groups, etc.), and so that those assignments are available for reporting/forcasting purposes. > This is the code fragment used to initialize the swimlanes: > ... > Map swimlanes = processDefinition.getTaskMgmtDefinition().getSwimlanes(); > Iterator itr = swimlanes.keySet().iterator(); > while(itr.hasNext()) { > Swimlane swimlane = (Swimlane)swimlanes.get(itr.next()); > SwimlaneInstance swi = pi.getTaskMgmtInstance().getInitializedSwimlaneInstance(new Execution > Context(pi.getRootToken()), swimlane); > //at this point, swi contains both actors and PooledActors that were specified in configuration and > populated with an appropriate AssignmentHandler > } > graphSession.saveProcessInstance(pi); > jbpmSession.commitTransaction(); > Thanks, > Britt -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-992) Make JBoss Cache build and run under JDK6

by Manik Surtani (JIRA)

Make JBoss Cache build and run under JDK6 ----------------------------------------- Key: JBCACHE-992 URL: http://jira.jboss.com/jira/browse/JBCACHE-992 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.BETA2 -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Commented: (JBAS-3071) MemoryLeak (redeployment) on EJB3

by Ortwin Glück (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3071?page=comments#action_12355292 ] Ortwin Glück commented on JBAS-3071: ------------------------------------ Maybe this helps to speed up the resoltion of this longstanding and extremely annoying bug: Deploy and undeploy an EJB3 component. In the JMX console go to jboss.ejb:service=EJBTimerService and call java.lang.String listTimers() You can see entries of the undeployed component. > MemoryLeak (redeployment) on EJB3 > --------------------------------- > > Key: JBAS-3071 > URL: http://jira.jboss.com/jira/browse/JBAS-3071 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB3 > Affects Versions: JBossAS-4.0.4.CR2 > Reporter: Clebert Suconic > Assigned To: Carlo de Wolf > Priority: Critical > Fix For: JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta3 > > > This might be caused by JBAS-3016: > But I'm seeing this strong reference: > org.jboss.mx.loading.UnifiedClassLoader3@33411906 > !--- org.jboss.ejb3.stateless.StatelessContainer@29610827 > We should make sure EJB3 packages are not leaking. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-890) zzzzzzzzzzzzzzzzzzzzzzzz

by naeem ahmad (JIRA)

zzzzzzzzzzzzzzzzzzzzzzzz ------------------------ Key: JBPM-890 URL: http://jira.jboss.com/jira/browse/JBPM-890 Project: JBoss jBPM Issue Type: Task Components: Documentation Reporter: naeem ahmad Assigned To: Tom Baeyens -- 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, 2 months

3
2
0 / 0

[JBoss JIRA] Created: (JGRP-344) Ignore bind address for (receive) sockets

by Bela Ban (JIRA)

Ignore bind address for (receive) sockets ----------------------------------------- Key: JGRP-344 URL: http://jira.jboss.com/jira/browse/JGRP-344 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 For multicast sockets, bind address defines the NIC which will be used to receive and send IP multicast packets. For unicast sockets (e.g. ServerSocket), this is an unnecessary restriction and bind address should be ignored. For example, if we define bind_addr=1.2.3.4, then we will be able to only receive packets on 1.2.3.4, but not 5.6.7.8 etc. However, currently bind_addr is used to define the *identity* of a member, so we still need to use it (although not set it in a socket). This will be easier once we have logical addresses. Email by Satya: Hi, I have found an issue which is to be fixed in 2.5. I want to know if my issue is realted to this issue. The description is as follows: If -Dbind.address or bind_addr are not set, JGroups picks the NIC to bind sockets to itself. However, especially for ServerSockets, this may not be desirable because we may want to have ServerSockets be able to receive packets through all interfaces, e.g. - NICs are 192.168.5.2, 192.168.0.2 and 127.0.0.1 (loopback) - When the bind address is set to 192.168.5.2, a given ServerSocket on port 7500 will *only accept packets from this NIC* - If someone connects to 192.168.0.2:7500 or 127.0.0.1:7500, the client will not be able to establish a connection because nobody is listening on those ports on the given NICs - If bind address was not set, this would be possible - Affected: FD_SOCK, FD_PING, TCP, TCP_NIO etc - We need to think about semantics for MulticastSockets where a wildcard address (not setting the bind address) means that the operating system picks the NIC, and *not* that the MulticastSocket will listen on all interfaces for incoming packets Regards, Satya. --- satya narayana <satya_461(a)yahoo.com> wrote: > > Hi Bela, > > > > It worked for me as long as I was stopping the NIC's > > which GMS address doesn't correspond. > > > > When I stopped the NIC which has the GMS Address > > specified by the member, I see them not > > communicating. > > > > If u have tried this and working for you , can you > > tell me the properties and options which u have > > specified to your demo ? -- 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, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBRULES-727) JBRMSService to log all actions to log4j

by Michael Neale (JIRA)

JBRMSService to log all actions to log4j ---------------------------------------- Key: JBRULES-727 URL: http://jira.jboss.com/jira/browse/JBRULES-727 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-667) IIOP binding

by Carlo de Wolf (JIRA)

IIOP binding ------------ Key: EJBTHREE-667 URL: http://jira.jboss.com/jira/browse/EJBTHREE-667 Project: EJB 3.0 Issue Type: Task Reporter: Carlo de Wolf Fix For: EJB 3.0 RC9 - FD Make IIOP binding work in the EJB3 stack. To use IIOP on an EJB bean, the following code is used: @RemoteBinding(factory=org.jboss.ejb3.iiop.IORFactory.class) -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-666) Throw javax.ejb.ConcurrentAccessException when two threads access the same SFSB instance

by Gavin King (JIRA)

Throw javax.ejb.ConcurrentAccessException when two threads access the same SFSB instance ---------------------------------------------------------------------------------------- Key: EJBTHREE-666 URL: http://jira.jboss.com/jira/browse/EJBTHREE-666 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Gavin King Priority: Critical Fix For: EJB 3.0 RC9 - FD See section 4.13.3 of the EJB Core Contracts specification. I need this for Seam. -- 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, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-653) No pooling for stateless session beans

by Guido Bening (JIRA)

No pooling for stateless session beans -------------------------------------- Key: EJBTHREE-653 URL: http://jira.jboss.com/jira/browse/EJBTHREE-653 Project: EJB 3.0 Issue Type: Bug Components: EJB3 Extensions Affects Versions: EJB 3.0 RC8 - FD Environment: OS: Windows XP SP2 JDK 1.5.0_06_b05 JBoss AS 4.0.4 GA Reporter: Guido Bening Scenario: Client VM calls a method on a EJB 2 Stateful Session Bean (SFSB) via the remote interface in a loop for 1000 times.Transaction starts on the application server. The SFSB method calls a method on a EJB3 Stateless Session Bean (SLSB) - via the remote interface (local interface makes no difference). The print out in the PostConstruct callback method of the EJB3 SLSB shows us, that a new bean instance was created for each of the 1000 method calls. Because of ThreadLocal pooling approach, we print out the Thread id too to show, that we always have the same Thread for each method call. CallBack method: /** * EJBCreate method. */ @PostConstruct public void ejb3Create() { System.out.println("New SessionBean " + this); System.out.println("Thread " + Thread.currentThread().getId()); setupBean(); } And the log for a few of the 1000 calls: ... 09:17:51,119 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@231ae2 09:17:51,129 INFO [STDOUT] Thread 97 09:17:51,139 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1662174 09:17:51,139 INFO [STDOUT] Thread 97 09:17:51,219 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@189f155 09:17:51,219 INFO [STDOUT] Thread 97 09:17:51,239 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1a82dfb 09:17:51,239 INFO [STDOUT] Thread 97 09:17:51,289 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@198813a 09:17:51,289 INFO [STDOUT] Thread 97 09:17:51,309 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@59eefd 09:17:51,309 INFO [STDOUT] Thread 97 09:17:51,359 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@2e3520 09:17:51,369 INFO [STDOUT] Thread 97 09:17:51,379 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1ed457 09:17:51,379 INFO [STDOUT] Thread 97 09:17:51,439 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1e1c7f3 09:17:51,439 INFO [STDOUT] Thread 97 09:17:51,449 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@15cb8ed 09:17:51,449 INFO [STDOUT] Thread 97 09:17:51,519 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1a4a949 09:17:51,519 INFO [STDOUT] Thread 97 09:17:51,529 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@19ae0a 09:17:51,529 INFO [STDOUT] Thread 97 09:17:51,589 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@567fa0 09:17:51,599 INFO [STDOUT] Thread 97 09:17:51,609 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@19956fe 09:17:51,609 INFO [STDOUT] Thread 97 09:17:51,659 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@150e574 09:17:51,669 INFO [STDOUT] Thread 97 09:17:51,679 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@aa46ad 09:17:51,679 INFO [STDOUT] Thread 97 ... -- 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, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-662) sfsb bean remove is not properly done

by Ben Wang (JIRA)

sfsb bean remove is not properly done -------------------------------------- Key: EJBTHREE-662 URL: http://jira.jboss.com/jira/browse/EJBTHREE-662 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Ben Wang Assigned To: Ben Wang Fix For: EJB 3.0 RC9 - FD Currently in StatefulRemoveInterceptor, when user calls @Remove, it removes directly the bean instance in the cache. However, this is incorrect when there is nested bean involved. Correct procedure is to do StatefulBeanContext.remove() that will remove it recursively. -- 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, 2 months

2
2
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 March 2007