January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Moved: (GPD-194) CLONE -JBDS - cannot generate a form for a task via (jBPM) GPD

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-194?page=all ] Koen Aers moved JBIDE-1589 to GPD-194: -------------------------------------- Project: JBoss jBPM GPD (was: Tools (JBoss Tools)) Key: GPD-194 (was: JBIDE-1589) Affects Version/s: jBPM jPDL Designer 3.1.1 (was: 2.0.0.GA) > CLONE -JBDS - cannot generate a form for a task via (jBPM) GPD > -------------------------------------------------------------- > > Key: GPD-194 > URL: http://jira.jboss.com/jira/browse/GPD-194 > Project: JBoss jBPM GPD > Issue Type: Bug > Affects Versions: jBPM jPDL Designer 3.1.1 > Environment: JBoss Developer Studio, Build id: 200712091205-nightly > and > Eclipse Europa + jbpm-jpdl-designer-3.0.13 Stable 9.2 MB 2007-01-25 > Reporter: Koen Aers > Assigned To: Koen Aers > Fix For: jBPM jPDL Designer 3.2.0.alpha1, jBPM jPDL Designer 3.1.2 > > > I'm unable to generate a new form for a task with either the 1.0 JBDS bits or Eclipse Europa + jbpm-jpdl-designer-3.0.13 Stable 9.2 MB 2007-01-25 > To recreate the problem - using the attached jBPM process project - it's based on the 'holiday request' jBPM demo - at the start task node, attempt to generate a form. > The screen displayed in the screenshot attachment is brought up - pressing OK has no effect. The form xhtml file is not created - and no error/sttaus message is displayed. > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (GPD-194) CLONE -JBDS - cannot generate a form for a task via (jBPM) GPD

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-194?page=all ] Koen Aers updated GPD-194: -------------------------- Fix Version/s: jBPM jPDL Designer 3.2.0.alpha1 jBPM jPDL Designer 3.1.2 > CLONE -JBDS - cannot generate a form for a task via (jBPM) GPD > -------------------------------------------------------------- > > Key: GPD-194 > URL: http://jira.jboss.com/jira/browse/GPD-194 > Project: JBoss jBPM GPD > Issue Type: Bug > Affects Versions: jBPM jPDL Designer 3.1.1 > Environment: JBoss Developer Studio, Build id: 200712091205-nightly > and > Eclipse Europa + jbpm-jpdl-designer-3.0.13 Stable 9.2 MB 2007-01-25 > Reporter: Koen Aers > Assigned To: Koen Aers > Fix For: jBPM jPDL Designer 3.2.0.alpha1, jBPM jPDL Designer 3.1.2 > > > I'm unable to generate a new form for a task with either the 1.0 JBDS bits or Eclipse Europa + jbpm-jpdl-designer-3.0.13 Stable 9.2 MB 2007-01-25 > To recreate the problem - using the attached jBPM process project - it's based on the 'holiday request' jBPM demo - at the start task node, attempt to generate a form. > The screen displayed in the screenshot attachment is brought up - pressing OK has no effect. The form xhtml file is not created - and no error/sttaus message is displayed. > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-2235) Server Controller Tasks: Throw error if normal shutdown fails

by Martin Vecera (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2235?page=all ] Martin Vecera reassigned JBAS-2235: ----------------------------------- Assignee: (was: Martin Vecera) > Server Controller Tasks: Throw error if normal shutdown fails > ------------------------------------------------------------- > > Key: JBAS-2235 > URL: http://jira.jboss.com/jira/browse/JBAS-2235 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Test Suite > Environment: jboss-4.0 tip > Reporter: Ryan Campbell > Fix For: JBossAS-5.0.0.Beta4 > > Attachments: jboss-test-diff > > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > Currently, when a server fails to respond to a shutdown request, the process is killed and the tests continue. > There should be an error thrown if the server fails to shutdown within the timeout period. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-2647) Remove potential deadlock condition from HASingletonSupport

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2647?page=comments#action_12393951 ] Dimitris Andreadis commented on JBAS-2647: ------------------------------------------ Brian, can you please update this dated task (and the parent task)? > Remove potential deadlock condition from HASingletonSupport > ----------------------------------------------------------- > > Key: JBAS-2647 > URL: http://jira.jboss.com/jira/browse/JBAS-2647 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: JBossAS-5.0.0.Beta4 > > > The startService() implementation HASingletonSupport inherits from HAServiceMBeanSupport has a slight potential for deadlock is a cluster topology change occurs while the singleton service itself is being deployed. The only known use case where this would occur is with the HASingletonDeployer service. > Details: > In Thread A > 1) HASingletonDeployerServices is being deployed, and therefore has synchronized on org.jboss.system.ServiceController. > 2) Calls DRM.registerListener() > 3) Call DRM.add() (this is the next line of code) > 4) As part of add processing, DRM callsback to the HASingleton. > 5) Inside a synchronized block in the callback method, singleton determines if it is the master node, goes on to do its work. > Problem occurs if a cluster topology change occurs between steps 2 and 3. In that case, the following would happen in another thread, Thread B. > 1) Topology changes, so DRM notifies listeners. > 2) Our HASingleton is registered as a listener, so step 5 above occurs. > 3) Since its the master, goes and tries to deploy things in deploy-hasingleton. > 4) Deployment can't proceed because Thread A has synchronized on org.jboss.system.ServiceController. > 5) Thread A can't proceed because Thread B is stuck inside the synchronized block in the callback method. Deadlock. > This is an unlikely scenario, but I'm marking this issue as major since if it does occur it deadlocks the node. > A likely fix will involve overriding the startService() implemetation so it doesn't rely on the callback to determine whether or not its the master node. Instead it directly does what the callback code does, and then registers as a listener. Have to be careful not to drop any topology changes in the middle. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-1407) Analytics to use Janino compiler

by Michael Neale (JIRA)

Analytics to use Janino compiler -------------------------------- Key: JBRULES-1407 URL: http://jira.jboss.com/jira/browse/JBRULES-1407 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.5 Reporter: Michael Neale Assigned To: Michael Neale Fix For: 4.1.0 -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1257) Create notification for buddy group change event

by Manik Surtani (JIRA)

Create notification for buddy group change event ------------------------------------------------ Key: JBCACHE-1257 URL: http://jira.jboss.com/jira/browse/JBCACHE-1257 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Buddy Replication Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.CR3, 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

16 years, 5 months

1
1
0 / 0

[JBoss JIRA] Commented: (JGRP-129) Logical addresses

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-129?page=comments#action_12393932 ] Bela Ban commented on JGRP-129: ------------------------------- Optimization: we could shorts which are indicex into a hashmap of logical addresses (which in turn map to physical addresses), and only send around the shorts. Need to make sure those are unique across the cluster though, probably via a short voting/election phase on startup in TP... > Logical addresses > ----------------- > > Key: JGRP-129 > URL: http://jira.jboss.com/jira/browse/JGRP-129 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.x > > > The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough: > - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper > - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC > - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on > - Network Address Translation: the sender's address might get changed by the NAT > DESIGN: > - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called. > - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true"). > - The logical addresses must be picked such that they cannot be reused after disconnect()/close(). -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JGRP-105) GossipRouter should additionally listen on IP multicast group and bridge traffic

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-105?page=all ] Bela Ban updated JGRP-105: -------------------------- Fix Version/s: 2.x (was: 2.7) > GossipRouter should additionally listen on IP multicast group and bridge traffic > -------------------------------------------------------------------------------- > > Key: JGRP-105 > URL: http://jira.jboss.com/jira/browse/JGRP-105 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.8 > Reporter: Bela Ban > Assigned To: Vladimir Blagojevic > Fix For: 2.x > > > GossipRouter should be augmented to not just route traffic between TCP endpoints, but also between an IP multicast group and all TCP endpoints. > It should be configured with the properties for a (multicast-based) group X, and then forward messages from X to all of its attached endpoints, and vice versa. > In the future, this concept could be extended to generic bridging functionality, which will allow to construct hierarchical messaging trees, similar to the MBone -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-628) Discovery: add cluster name to discovery request to be able to discard responses from different clusters

by Bela Ban (JIRA)

Discovery: add cluster name to discovery request to be able to discard responses from different clusters -------------------------------------------------------------------------------------------------------- Key: JGRP-628 URL: http://jira.jboss.com/jira/browse/JGRP-628 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6.1, 2.7 When we have 2 groups ONE and TWO: ONE: 228.8.8.8:7500 and TWO: 228.1.2.3:7500 In some cases, they will receive each other's traffic (http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic). Assume ONE has members {A,B,C} and TWO has no members yet. When D (in cluster TWO) starts up and sends out a discovery request, it might also receive discovery responses from ONE (A,B,C). D might now identify A as coordinator and send a JOIN-REQ to A. However, A will discard that request as the group name of D's request is TWO rather than ONE ! Result: D's JOIN-REQ will hang ! Note that the transport (TP) does drop messages from different clusters, but this happens only after the new member has joined the group, so discovery requests/responses from different groups are *not* discarded. Tasks: - Verify that the transport-name matching algorithm in TP is correct - Confirm that - on initial discovery - discovery requests and responses are not matched -- 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, 6 months

1
6
0 / 0

[JBoss JIRA] Created: (JGRP-656) Flag to determine when a message is considered delivered

by Bela Ban (JIRA)

Flag to determine when a message is considered delivered -------------------------------------------------------- Key: JGRP-656 URL: http://jira.jboss.com/jira/browse/JGRP-656 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.7 Attachments: tmp.java Okay, I know what the problem is. When a multicast message is received from sender A, then a lock is acquired for A (or we block until A's done processing the message and releases the lock). When the receive() method would send more messages down the stack, that lock might get held for potentially a long time. So I made the following change: I assume that calling down() from within receive() means that the message has been *delivered*, so I release the lock held for A and someone else can now acquire that lock. If you comment the lines of ProtocolStack.down() and recompile JGroups, then you will always see a count of 1: public Object down(Event evt) { ReentrantLock lock=locks.remove(Thread.currentThread()); //if(lock != null && lock.isHeldByCurrentThread()) { // lock.unlock(); //if(log.isTraceEnabled()) // log.trace("released lock held by " + Thread.currentThread()); //} if(top_prot != null) return top_prot.down(evt); return null; } The issue here is that I don't want to block incoming calls just because the receive() method sends other messages. This is described in http://jira.jboss.com/jira/browse/JGRP-535. I might introduce a flag in ProtocolStack to configure this behavior... -- 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, 6 months

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008