November 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-2463) Stop using Apple / Mac icons in the default homepage installed with the GateIn portal

by Ken Chau (JIRA)

Stop using Apple / Mac icons in the default homepage installed with the GateIn portal ------------------------------------------------------------------------------------- Key: JBPORTAL-2463 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2463 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 3.0 Final Reporter: Ken Chau Assignee: Sohil Shah Fix For: 3.0 Final Apple icons are being used, consider using free icon sets such as: http://www.fatcow.com/free-icons/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-1028) RpcDispatcher locked

by Holger Rehn (JIRA)

RpcDispatcher locked -------------------- Key: JGRP-1028 URL: https://jira.jboss.org/jira/browse/JGRP-1028 Project: JGroups Issue Type: Bug Affects Versions: 2.7 Reporter: Holger Rehn Assignee: Bela Ban This follows up forum post https://sourceforge.net/forum/message.php?msg_id=7585933. Summary: There are circumstances that lead to RpcDispatcher being locked without obvious reason in the following state: "ICP1" daemon prio=10 tid=0x000000002ce25000 nid=0x125c waiting on condition [0x00000000377df000..0x00000000377df810] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x0000000024b45ee0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2054) at org.jgroups.blocks.GroupRequest.collectResponses(GroupRequest.java:512) at org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:266) at org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:231) at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:576) at org.jgroups.blocks.RpcDispatcher.callRemoteMethod(RpcDispatcher.java:323) ... The problem appears with different versions of JGroups (2.7, 2.8 at least) and all the different stack configurations I tried so far (see attached project for a few examples). As I already described in the mentioned thread, one of our test machines seems to play a special role for reproducing the error. Now that I have a working test for this I discovered another weird thing: the direction for sending data plays an important role. If my workstation is sending data to the test server, JGroups stalls after a few seconds. If the server is sending data to my machine, the problem simply disappears. However, I have found another way to get JGroups blocking that I hope could have the same cause. Please find attached an Eclipse project containing a simple test class you could either start as a Java application or as a TestNG/JUnit test. Simply run this on different machines or multiple instances on the same machine (I've tested with 4 different machines including a VMWare system, any combination of these and every machine on it's own showed the described blocking immediately). The test just joins a channel and if it's the first member, it goes into "primary" mode, meaning it will start sending byte arrays via RPCDispatcher to any other member of the channel as soon as there is at least one other member. If an instance of the test finds itself to be the last member in the channel, it also switches to primary mode to allow test nodes to be started and stopped arbitrarily. The problem(s) showed by this test are: 1. If timing is right and the data send in the RPC is small enough, JGroups blocks instantly without getting even a single RPC through. This can be reproduced on any machine (remove the Thread.sleep(1) from line 80 if you don't get the error). 2. JGroups blocks at some point after a random number of RPC calls with random data succeeded. After the first blocked call has been aborted by a TimeoutException, any further RPC will end up blocking, as well. This seems to depend on the environment and currently can only be safely reproduced here when the RPC target is a certain machine. This also doesn't seem to happen if using fixed size RPC data that is known to get through at least once. You could try reproducing this in your environment by commenting/uncommenting a few lines in the test class (see code comments). I really hope both problems have the same cause and since none of them is exactly what we encounter in our product (no TimeoutException there, blocking after a fixed amount of calls) I can just pray fixing problem 1 will solve the others as well. Cheers, momo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JGRP-1089) org.jgroups.util.UUID.toString() should print the physical address too

by Galder Zamarreno (JIRA)

org.jgroups.util.UUID.toString() should print the physical address too ---------------------------------------------------------------------- Key: JGRP-1089 URL: https://jira.jboss.org/jira/browse/JGRP-1089 Project: JGroups Issue Type: Task Reporter: Galder Zamarreno Assignee: Bela Ban Fix For: 2.8 In Infinispan, we print the local address: 2009-11-03 13:18:36,377 3125 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (main:) Cache local address is localhost.localdomain-32544 This effectively calls org.jgroups.util.UUID which implements address. It's be really useful if UUID's toString() also contained the physical address in the same way that you get it when GMS.print_address is on. This would help debugging when GMS.print_address is off. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-1092) UNICAST: loopback="true" can destroy ordering

by Bela Ban (JIRA)

UNICAST: loopback="true" can destroy ordering --------------------------------------------- Key: JGRP-1092 URL: https://jira.jboss.org/jira/browse/JGRP-1092 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 In UNICAST.down(), when loopback is true, a message is sent back up on the same thread. Because the message is not added to the retransmission table, ordering is undefined, ie. multiple threads sending unicast messages has completely undefined ordering. Possible solutions: - We define the semantics of loopback and declare ordering undefined (some apps mightr be OK with this) - We deprecate and remove loopback as TP already implemements loopback (this was chosen, but needs to be revisited) - We add the message to the retransmission table and them remove it again and pass it up. essentially what we do in TP, so it is duplicate functionality. Not recommended -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7242) Include mod_cluster

by Jason T. Greene (JIRA)

Include mod_cluster ------------------- Key: JBAS-7242 URL: https://jira.jboss.org/jira/browse/JBAS-7242 Project: JBoss Application Server Issue Type: Component Upgrade Security Level: Public (Everyone can see) Reporter: Jason T. Greene Assignee: Brian Stansberry -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 8 months

4
5
0 / 0

[JBoss JIRA] Created: (JGRP-1091) NAKACK: further optimizations

by Bela Ban (JIRA)

NAKACK: further optimizations ----------------------------- Key: JGRP-1091 URL: https://jira.jboss.org/jira/browse/JGRP-1091 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Sending of a message in down(): - When sending a message in down(), we always grab the NakReceiverWindow for local_addr - A ref to the window can be cached, so we can eliminate the Map.get(local_addr) altogether -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBID-190) Management UI for IDM, preference is GWT

by Jeff Yu (JIRA)

Management UI for IDM, preference is GWT ---------------------------------------- Key: JBID-190 URL: https://jira.jboss.org/jira/browse/JBID-190 Project: JBoss Identity Issue Type: Task Components: IDM Affects Versions: idm-1.0.0.Beta1 Reporter: Jeff Yu Assignee: Jeff Yu Have a Management UI (prefer to use GWT) for the identity CRUD, also for its configuration like DB connection etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBID-51) XML Encryption - configuration changes to handle encrypted attribute and encrypted assertion

by Anil Saldhana (JIRA)

XML Encryption - configuration changes to handle encrypted attribute and encrypted assertion -------------------------------------------------------------------------------------------- Key: JBID-51 URL: https://jira.jboss.org/jira/browse/JBID-51 Project: JBoss Identity Issue Type: Sub-task Components: IDM Reporter: Anil Saldhana Assignee: Anil Saldhana -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBID-196) deploy IDM into Tomcat

by Jeff Yu (JIRA)

deploy IDM into Tomcat ---------------------- Key: JBID-196 URL: https://jira.jboss.org/jira/browse/JBID-196 Project: JBoss Identity Issue Type: Task Components: IDM Reporter: Jeff Yu Assignee: Jeff Yu Deploy IDM into Tomcat if possible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBID-72) Convert idm wikis into docbook, and using jdocbook plugin

by Jeff Yu (JIRA)

Convert idm wikis into docbook, and using jdocbook plugin --------------------------------------------------------- Key: JBID-72 URL: https://jira.jboss.org/jira/browse/JBID-72 Project: JBoss Identity Issue Type: Feature Request Components: IDM Affects Versions: 1.0.0.alpha2 Reporter: Jeff Yu Assignee: Jeff Yu Convert idm wikis into docbook, and using jdocbook plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 8 months

3
11
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 November 2009