September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Moved: (GPD-376) candidate-groups info lost

by Tom Baeyens (JIRA)

[ https://jira.jboss.org/jira/browse/GPD-376?page=com.atlassian.jira.plugin... ] Tom Baeyens moved JBPM-2496 to GPD-376: --------------------------------------- Project: jBPM GPD (was: jBPM) Key: GPD-376 (was: JBPM-2496) Component/s: (was: GPD) Affects Version/s: (was: jBPM 4.0) Security: (was: Public) > candidate-groups info lost > -------------------------- > > Key: GPD-376 > URL: https://jira.jboss.org/jira/browse/GPD-376 > Project: jBPM GPD > Issue Type: Bug > Reporter: Joram Barrez > > When manually adding 'candidate-groups="administrator" ' to a task in the XML, this field is lost after having saved, gone back to the diagram and back to the xml. > Also the PNG is messed up. -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (SECURITY-434) Ensure log.isTraceEnabled usage

by Anil Saldhana (JIRA)

Ensure log.isTraceEnabled usage ------------------------------- Key: SECURITY-434 URL: https://jira.jboss.org/jira/browse/SECURITY-434 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: JBossSX, Security SPI Affects Versions: JBossSecurity_2.0.4 Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: JBossSecurity_2.0.4.SP1 Ensure log.trace and log.debug statements are all under the umbrella log.isTraceEnabled and log.isDebugEnabled calls -- 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

14 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (SECURITY-435) Release JBoss Security 2.0.4.SP1

by Anil Saldhana (JIRA)

Release JBoss Security 2.0.4.SP1 -------------------------------- Key: SECURITY-435 URL: https://jira.jboss.org/jira/browse/SECURITY-435 Project: JBoss Security and Identity Management Issue Type: Release Security Level: Public (Everyone can see) Components: JBossSX, Security SPI Affects Versions: JBossSecurity_2.0.4 Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: JBossSecurity_2.0.4.SP1 Release with the log.isTraceEnabled checks. -- 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

14 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1040) Provide better seperation of test case output in the logs

by Richard Achmatowicz (JIRA)

Provide better seperation of test case output in the logs --------------------------------------------------------- Key: JGRP-1040 URL: https://jira.jboss.org/jira/browse/JGRP-1040 Project: JGroups Issue Type: Feature Request Affects Versions: 2.8 Reporter: Richard Achmatowicz Assignee: Bela Ban Priority: Minor Fix For: 2.8 It's difficult to read logging output when the output from all test methods within a test class is streamed together. Added a small line separator to that output which formerly looked like this: org.jgroups.tests.ConnectTest: 27654 [WARN] UDP: - could not bind to /235.10.10.47 (IPv4 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.BindException: Cannot assign requested address 27685 [WARN] UDP: - receive buffer of socket java.net.DatagramSocket@ec7c94 was set to 20MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) 27685 [WARN] UDP: - receive buffer of socket java.net.MulticastSocket@1e6f7cb was set to 25MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) ------------------------------------------------------------------- GMS: address=localhost.localdomain-22283, cluster=ConnectTest.testgroup-5, physical address=3ffe:ffff:100:f101:0:0:0:1:56075 ------------------------------------------------------------------- 29779 [WARN] UDP: - could not bind to /235.10.10.47 (IPv4 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.BindException: Cannot assign requested address 29779 [WARN] UDP: - receive buffer of socket java.net.DatagramSocket@1b8aeb1 was set to 20MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) 29779 [WARN] UDP: - receive buffer of socket java.net.MulticastSocket@1d4ea6c was set to 25MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) ------------------------------------------------------------------- GMS: address=localhost.localdomain-20311, cluster=ConnectTest.testgroup-6, physical address=3ffe:ffff:100:f101:0:0:0:1:33651 ------------------------------------------------------------------- 31785 [WARN] UDP: - could not bind to /235.10.10.47 (IPv4 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.BindException: Cannot assign requested address 31786 [WARN] UDP: - receive buffer of socket java.net.DatagramSocket@2f06b6 was set to 20MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) 31786 [WARN] UDP: - receive buffer of socket java.net.MulticastSocket@161c602 was set to 25MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) ------------------------------------------------------------------- GMS: address=localhost.localdomain-20311, cluster=ConnectTest.testgroup-5, physical address=3ffe:ffff:100:f101:0:0:0:1:40461 ------------------------------------------------------------------- 31913 [WARN] NAKACK: - localhost.localdomain-20311: discarded message from non-member localhost.localdomain-22283, my view is [localhost.localdomain-20311|0] [localhost.localdomain-20311] 32554 [WARN] UDP: - could not bind to /235.10.10.54 (IPv4 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.BindException: Cannot assign requested address 32555 [WARN] UDP: - receive buffer of socket java.net.DatagramSocket@548719 was set to 20MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) 32556 [WARN] UDP: - receive buffer of socket java.net.MulticastSocket@1719d5b was set to 25MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) ------------------------------------------------------------------- now looks like this: org.jgroups.tests.ConnectTest: ================ Starting test testDisconnectConnectSendTwo ================ 27654 [WARN] UDP: - could not bind to /235.10.10.47 (IPv4 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.BindException: Cannot assign requested address 27685 [WARN] UDP: - receive buffer of socket java.net.DatagramSocket@ec7c94 was set to 20MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) 27685 [WARN] UDP: - receive buffer of socket java.net.MulticastSocket@1e6f7cb was set to 25MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) ------------------------------------------------------------------- GMS: address=localhost.localdomain-22283, cluster=ConnectTest.testgroup-5, physical address=3ffe:ffff:100:f101:0:0:0:1:56075 ------------------------------------------------------------------- 29779 [WARN] UDP: - could not bind to /235.10.10.47 (IPv4 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.BindException: Cannot assign requested address 29779 [WARN] UDP: - receive buffer of socket java.net.DatagramSocket@1b8aeb1 was set to 20MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) 29779 [WARN] UDP: - receive buffer of socket java.net.MulticastSocket@1d4ea6c was set to 25MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) ------------------------------------------------------------------- GMS: address=localhost.localdomain-20311, cluster=ConnectTest.testgroup-6, physical address=3ffe:ffff:100:f101:0:0:0:1:33651 ------------------------------------------------------------------- 31785 [WARN] UDP: - could not bind to /235.10.10.47 (IPv4 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.BindException: Cannot assign requested address 31786 [WARN] UDP: - receive buffer of socket java.net.DatagramSocket@2f06b6 was set to 20MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) 31786 [WARN] UDP: - receive buffer of socket java.net.MulticastSocket@161c602 was set to 25MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) ------------------------------------------------------------------- GMS: address=localhost.localdomain-20311, cluster=ConnectTest.testgroup-5, physical address=3ffe:ffff:100:f101:0:0:0:1:40461 ------------------------------------------------------------------- 31913 [WARN] NAKACK: - localhost.localdomain-20311: discarded message from non-member localhost.localdomain-22283, my view is [localhost.localdomain-20311|0] [localhost.localdomain-20311] ================ Starting test testDisconnectConnectTwo ================ 32554 [WARN] UDP: - could not bind to /235.10.10.54 (IPv4 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.BindException: Cannot assign requested address 32555 [WARN] UDP: - receive buffer of socket java.net.DatagramSocket@548719 was set to 20MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) 32556 [WARN] UDP: - receive buffer of socket java.net.MulticastSocket@1719d5b was set to 25MB, but the OS only allocated 16.78MB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) ------------------------------------------------------------------- Just added the following to ChannelTestBase: @BeforeMethod protected void startTestHeader(java.lang.reflect.Method m) { System.out.println("\n================ Starting test " + m.getName() + " ================\n"); } -- 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

14 years, 8 months

2
4
0 / 0

[JBoss JIRA] Moved: (GPD-375) Show activity name

by Tom Baeyens (JIRA)

[ https://jira.jboss.org/jira/browse/GPD-375?page=com.atlassian.jira.plugin... ] Tom Baeyens moved JBPM-2484 to GPD-375: --------------------------------------- Project: jBPM GPD (was: jBPM) Key: GPD-375 (was: JBPM-2484) Component/s: (was: GPD) Affects Version/s: (was: jBPM 4.0) Security: (was: Public) > Show activity name > ------------------ > > Key: GPD-375 > URL: https://jira.jboss.org/jira/browse/GPD-375 > Project: jBPM GPD > Issue Type: Feature Request > Reporter: Joram Barrez > Priority: Minor > > Currently when using a decision activity, the activity name is not shown on the diagram (only in the properties). > It would be useful to have the name in the diagram too. -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-1732) Message Sucker should be able to re-connect once it's connection is broken.

by Howard Gao (JIRA)

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1732?page=com.atlassian.ji... ] Howard Gao commented on JBMESSAGING-1732: ----------------------------------------- Here is how i want to fix it: On creation of each remote connection, register an ExceptionListener. The listener's onException() method will be called if the connection has a problem. In onException(), first suspend all suckers that associated with this connection and then stop the connection. Suspending suckers means we stop and close the cosumer, but we don't stop the producer, because the producer is always local. Then we start to retry the connection. We provide two parameters in messaging-service.xml, one is retry times (default -1, means retry forever), the other is retry interval (millis). Once retry successful, we resume the suckers, meaning we use the new session to create new consumers and restore the consuming state of the suckers. > Message Sucker should be able to re-connect once it's connection is broken. > --------------------------------------------------------------------------- > > Key: JBMESSAGING-1732 > URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1732 > Project: JBoss Messaging > Issue Type: Bug > Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA > Reporter: Howard Gao > Assignee: Howard Gao > Fix For: 1.4.0.SP3.CP09, 1.4.5.GA > > > The connection that message suckers uses to pull messages from other nodes in the cluster is created once and for all. If the connection is broken, the messages will not be pulled away. Actually it should try reconnect whenever a broken connection is found. -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Moved: (GPD-374) It is not possible to define variable mapping in jBPM process editor Created: 08/Jan/08 04:26 AM Updated: 10/Mar/09 05:41 AM

by Tom Baeyens (JIRA)

[ https://jira.jboss.org/jira/browse/GPD-374?page=com.atlassian.jira.plugin... ] Tom Baeyens moved JBPM-2274 to GPD-374: --------------------------------------- Project: jBPM GPD (was: jBPM) Key: GPD-374 (was: JBPM-2274) Component/s: (was: GPD) Affects Version/s: (was: jBPM 3.2.3) Security: (was: Public) > It is not possible to define variable mapping in jBPM process editor Created: 08/Jan/08 04:26 AM Updated: 10/Mar/09 05:41 AM > ------------------------------------------------------------------------------------------------------------------------------- > > Key: GPD-374 > URL: https://jira.jboss.org/jira/browse/GPD-374 > Project: jBPM GPD > Issue Type: Feature Request > Environment: Environment: FC7/Eclipse Europa/jPDL Designer 3.1.0.SP1 > Reporter: Trevor Kirby > Assignee: Tom Baeyens > > It is not possible to edit XML content of bpmToEsbVars and esbToBpmVars elements. > This now requires to edit process definition twice - once in graphical designer and second time in text editor to define mapping. This is very inconveniet for user as he frequently lose process arrangement as it is rearranged after this modification. > 1) I do not know if the jPDL designer supports editation of nested XML element > 2) If he supports it then we should find out if this is problem of only one platform or general deficiency -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCL-114) org.jboss.classloader.spi.base.BaseClassLoader.loadClass is inefficient on loading recurring classes

by Carlo de Wolf (JIRA)

org.jboss.classloader.spi.base.BaseClassLoader.loadClass is inefficient on loading recurring classes ---------------------------------------------------------------------------------------------------- Key: JBCL-114 URL: https://jira.jboss.org/jira/browse/JBCL-114 Project: JBoss ClassLoader Issue Type: Bug Affects Versions: JBossCL.2.0.6.GA Reporter: Carlo de Wolf Priority: Blocker Fix For: JBossCL.2.0.7.GA Whenever something asks for a class to be loaded we run into lock contention problems on org.jboss.classloader.spi.base.BaseClassLoader. -- 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

14 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-7234) Reduce failed classloading logs from ERROR to WARN

by Dennis Reed (JIRA)

Reduce failed classloading logs from ERROR to WARN -------------------------------------------------- Key: JBAS-7234 URL: https://jira.jboss.org/jira/browse/JBAS-7234 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-5.1.0.GA Reporter: Dennis Reed Assignee: Dennis Reed LoadMgr3 logs a failure to load a class as ERROR, but this is not always an error. For example, Seam attempts to load clustering classes, and catches the exception to disable its PojoCache. This should not be logged as an ERROR. -- 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

14 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-1041) Provide more DEBUG level information on Channel resources used when running tests in parallel

by Richard Achmatowicz (JIRA)

Provide more DEBUG level information on Channel resources used when running tests in parallel --------------------------------------------------------------------------------------------- Key: JGRP-1041 URL: https://jira.jboss.org/jira/browse/JGRP-1041 Project: JGroups Issue Type: Feature Request Affects Versions: 2.8 Reporter: Richard Achmatowicz Assignee: Richard Achmatowicz Priority: Minor Fix For: 2.8 When running tests in parallel under testng, the JGroups testsuite provides mechanisms to allocate channel resources (udp.mcast_addr, udp..mcast_port, bind_port, port_range) in such a way that JGroups channels in different tests do not interfere with each other. This is done by allocating non-overlapping ranges of addresses and ports. However, there is a rather complex trail to follow when trying to find which addresses will be picked up by tests: * build.xml + build.properties, which feed to * runtest parameters, which feed to * testng parameters, which feed to * ChannelTestBase parameters, which feed to * test case paramaters At present, it is not easy to discover which values a test is using for the channel resources mentioned above. It would be nice to be able to see this information in the DEBUG logs, to aid in resolving problesm with the wrong addresses being used. -- 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

14 years, 8 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2009