September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2667) DroolsSpringJpaManager should use different Entity Managers for CMD and APP.

by Esteban Aliverti (JIRA)

DroolsSpringJpaManager should use different Entity Managers for CMD and APP. ---------------------------------------------------------------------------- Key: JBRULES-2667 URL: https://jira.jboss.org/browse/JBRULES-2667 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.1.0.FINAL Reporter: Esteban Aliverti Assignee: Esteban Aliverti Fix For: 5.1.1.FINAL Just like DefaultJpaManager does, DroolsSpringJpaManager must use different Enitity Managers: one for CMD transactions and another one for APP transactions. One of the visible effects of this issue is that flow's timers doesn't run properly using spring. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-8454) Domain Repository syncing

by Jason Greene (JIRA)

Domain Repository syncing ------------------------- Key: JBAS-8454 URL: https://jira.jboss.org/browse/JBAS-8454 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Jason Greene Fix For: 7.0.0.M1 Mechanism for SMs to pull content from a DC. Also some SMs might be able to become a DC, and they would need the full content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-8183) Naming service configuration schema

by Brian Stansberry (JIRA)

Naming service configuration schema ----------------------------------- Key: JBAS-8183 URL: https://jira.jboss.org/browse/JBAS-8183 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Domain Management, Naming Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.0.0.M1 Domain configuratio schema for the naming server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
3
0 / 0

[JBoss JIRA] Created: (JGRP-1241) FD_ALL: make more suited for large clusters

by Bela Ban (JIRA)

FD_ALL: make more suited for large clusters ------------------------------------------- Key: JGRP-1241 URL: https://jira.jboss.org/browse/JGRP-1241 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.11 [(Edited) email reply to David Forget] FD_ALL provides a mechanism to detect rapidly when several nodes leave the groups at the same time. Once a failure is detected by a member of the cluster, a SUSPECT message is multicast to all nodes. Then, another logic takes place in all other nodes call VERIFY_SUSPECT. This is to give one last chance to the suspected node before it is removed from the view. The default configuration (udp.xml) makes it so that each node will then send 1 UDP messages to the suspected node which, if still alive, would reply with 1 UDP messages. Since we are running many nodes on the same host and each of these nodes are heavily multithreaded and running in a JVM with garbage collection, it happens that a false failure is detected. The consequences of this scenario given the current configuration result in an excessive number of messages sent on UDP. For example, in a 300 nodes cluster a single false failure case results in roughly 2 verify suspect messages (ARE_YOU_ALIVE+I_AM_NOT_DEAD) x 298 nodes that process the suspect message x 299 nodes that detect the failure = ~180 000 UDP messages {assuming that all other nodes detect the false failure in a very short period of time (This is the worst case)}. This network flood can lead to more false detection and more UDP messages up to a network saturation and eventually a complete cluster / network degradation already know as "UDP Storm"... So 300 nodes multicast the SUSPECT message. That's 300 (multicast) messages TOTAL. Then every one of those (300*num_msgs) unicasts an ARE_YOU_DEAD message to the suspected member S. Since num_msgs=1, that's another 300 unicast messages, so our total is now 600. The suspected member S now gets 300 unicasts and - as a response - send 300 unicast I_AM_NOT_DEAD responses. So now the total is 900 messages (300 multicasts + (300 unicasts * num_msgs) + 300 unicasts. I can't follow your computation above with 180'000 messages !? SOLUTION #1: However, one thing we could is the following: similar to STABLE and sending of stability messages, instead of multicasting out a SUSPECT message immediately, we could schedule a task which goes off in a random period in range [1 .. max_mcast_wait_time]. Reception of a SUSPECT message for the same suspected member cancels this timer. The effect of this staggered way of multicasting SUSPECT messages would be that ideally only 1 member multicasts a SUSPECT message. That's already a huge improvement and results in <1 SUSPECT multicast> + <2 * 300 unicast messages (in VERIFY_SUSPECT)>... SOLUTION #2 In a second step what we could also do is to change VERIFY_SUSPECT, and have only the first N nodes in a cluster run the ARE_YOU_DEAD algorithm. This is similar to what I recently implemented in [1] to make discovery scale to large clusters. WDYT ? [1] https://jira.jboss.org/browse/JGRP-1181 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
8
0 / 0

[JBoss JIRA] Created: (JBRULES-2692) Remove broken and unused guvnor modules (dead code)

by Geoffrey De Smet (JIRA)

Remove broken and unused guvnor modules (dead code) --------------------------------------------------- Key: JBRULES-2692 URL: https://jira.jboss.org/browse/JBRULES-2692 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.1.1.FINAL Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Priority: Minor Fix For: 5.2.0.M1 Possibly everything under trunk/drools-guvnor/modules Especially video Maybe not the bpel part -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-8478) BlockingExecutor support

by Jesper Pedersen (JIRA)

BlockingExecutor support ------------------------ Key: JBAS-8478 URL: https://jira.jboss.org/browse/JBAS-8478 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jesper Pedersen Assignee: David Lloyd Fix For: 7.0.0.M1 We need to have support for a BlockingExector (domain.xml / Service<>) - like org.jboss.threads.QueueExecutor. It should be possible to configure a RejectingExecutor as the handoff for the pool. Ideally it should be possible to configure multiple of these types of pools as the JCA WorkManager component needs a pool for short running jobs and another for long running jobs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-8484) Upgrade PicketBox libraries to 3.0.0.CR2

by Marcus Moyses (JIRA)

Upgrade PicketBox libraries to 3.0.0.CR2 ---------------------------------------- Key: JBAS-8484 URL: https://jira.jboss.org/browse/JBAS-8484 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Security Affects Versions: 6.0.0.M5 Reporter: Marcus Moyses Assignee: Marcus Moyses Fix For: 6.0.0.CR1 Need to upgrade security libraries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
4
0 / 0

[JBoss JIRA] Created: (JBCOMMON-115) CVE-2009-2693

by Mike Millson (JIRA)

CVE-2009-2693 ------------- Key: JBCOMMON-115 URL: https://jira.jboss.org/browse/JBCOMMON-115 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Components: common-old (1.x) Affects Versions: 1.0.0.GA, 1.2.1.GA Reporter: Mike Millson CVE-2009-2693: When deploying WAR files, the WAR files were not checked for directory traversal attempts. This allows an attacker to create arbitrary content outside of the web root by including entries such as ../../bin/catalina.sh in the WAR. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-8433) WARs with no classes (but with beans.xml) fail to deploy

by Marius Bogoevici (JIRA)

WARs with no classes (but with beans.xml) fail to deploy -------------------------------------------------------- Key: JBAS-8433 URL: https://jira.jboss.org/browse/JBAS-8433 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Weld/CDI Reporter: Marius Bogoevici Assignee: Marius Bogoevici Priority: Critical Fix For: 6.0.0.CR1 This currently causes a number of TCK tests to fail, see: http://hudson.qa.jboss.com/hudson/view/TCK6/job/Weld-tck-dist-incontainer... The actual error is thrown here: Caused by: org.jboss.util.NotImplementedException at org.jboss.weld.integration.deployer.env.ArchiveDiscoveryDeployer.deploy(ArchiveDiscoveryDeployer.java:117) Basically, the current deployer implementation does not support wars with no CP, but with WB files, although such deployments can exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
3
0 / 0

[JBoss JIRA] Created: (JBBUILD-648) spy:memcached:jar:2.5 missing in its third party repository

by Trustin Lee (JIRA)

spy:memcached:jar:2.5 missing in its third party repository ----------------------------------------------------------- Key: JBBUILD-648 URL: https://jira.jboss.org/browse/JBBUILD-648 Project: JBoss Build System Issue Type: Bug Components: Artifact Repositories Reporter: Trustin Lee The following directory is empty: https://repository.jboss.org/nexus/content/repositories/spy-releases/spy/... where proper poms and jars are expected. The URLs of the important artifacts are:: http://bleu.west.spy.net/~dustin/m2repo/spy/memcached/2.5/memcached-2.5.pom http://bleu.west.spy.net/~dustin/m2repo/spy/memcached/2.5/memcached-2.5.jar http://bleu.west.spy.net/~dustin/m2repo/spy/memcached/2.5/memcached-2.5-s... http://bleu.west.spy.net/~dustin/m2repo/spy/memcached/2.5/memcached-2.5-j... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
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 2010