October 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2268) Unknown Parser Error when spreading rule condition over multiple lines

by Jeremy Ary (JIRA)

Unknown Parser Error when spreading rule condition over multiple lines ---------------------------------------------------------------------- Key: JBRULES-2268 URL: https://jira.jboss.org/jira/browse/JBRULES-2268 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.0.CR1 Environment: XP-SP3, eclipse 3.4.2, 5.0.0.CR1 Reporter: Jeremy Ary Assignee: Mark Proctor Full message: Unknown error while parsing. This is a bug. Please contact the Development team. To recreate: I broke a condition over multiple lines and mistakenly misgrouped my parentheses, leading to an unknown error while parsing: {code} rule "recreate bug" when Loan ( amount >= 175000 ) && ( program == "FHA" ) ) then modify (queueList) { add (QueueIds.UWENTRY) } end {code} When corrected to the following, the rule is parsed properly: {code} rule "recreate bug" when Loan ( ( amount >= 175000 ) && ( program == "FHA" ) ) then modify (queueList) { add (QueueIds.UWENTRY) } end {code} -- 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

15 years, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-8486) DataSourcePersistentManager error with FORM login

by Brian Stansberry (JIRA)

DataSourcePersistentManager error with FORM login ------------------------------------------------- Key: JBAS-8486 URL: https://jira.jboss.org/browse/JBAS-8486 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 6.0.0.CR1 Upstream issue for JBPAPP-5171 -- see that issue for further discussion. When using the DataSourcePersistentManager [1] to store web sessions, submitting a FORM login page results in a 408 error because the session is not found. The initial request for the protected resource sets the JSESSIONID cookie and returns the login form. But the session is not saved in the database, so submitting the form results in a 408 error. If the session already exists prior to the request for the protected resource, it works correctly. [1] http://community.jboss.org/wiki/HAWebSessionsviaDatabasePersistence -- 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

15 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8461) Update the DC<-->SM communication to use non-persistent connections

by John Bailey (JIRA)

Update the DC<-->SM communication to use non-persistent connections ------------------------------------------------------------------- Key: JBAS-8461 URL: https://jira.jboss.org/browse/JBAS-8461 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: John Bailey Assignee: John Bailey Fix For: 7.0.0.M1 -- 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

15 years, 4 months

1
1
0 / 0

[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

15 years, 4 months

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

15 years, 4 months

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

15 years, 4 months

3
3
0 / 0

[JBoss JIRA] Assigned: (JBAS-8483) errors injecting the Weld BeanManager.

by Marius Bogoevici (JIRA)

[ https://jira.jboss.org/browse/JBAS-8483?page=com.atlassian.jira.plugin.sy... ] Marius Bogoevici reassigned JBAS-8483: -------------------------------------- Assignee: Marius Bogoevici > errors injecting the Weld BeanManager. > -------------------------------------- > > Key: JBAS-8483 > URL: https://jira.jboss.org/browse/JBAS-8483 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Affects Versions: 6.0.0.M5 > Environment: jboss as 6 milestone 5 > Reporter: nimo stephan > Assignee: Marius Bogoevici > > The same weld-war does work in jboss as 6 milestone 4. Deploying it in jboss as 6 milestone 5 does work, only when invoking a bean, then weld throws exception: > (The full stacktrace can be seen here: http://community.jboss.org/thread/157055) > 10:57:33,719 SEVERITY [javax.enterprise.resource.webcontainer.jsf.application] javax.ejb.EJBException: java.lang.RuntimeException: Unable to inject jndi dependency: env/org.jboss.weld.integration.ejb.SessionBeanInterceptor/beanManager into property org.jboss.weld.integration.ejb.SessionBeanInterceptor.beanManager: MyWAR not bound: javax.faces.el.EvaluationException: javax.ejb.EJBException: java.lang.RuntimeException: Unable to inject jndi dependency: env/org.jboss.weld.integration.ejb.SessionBeanInterceptor/beanManager into property org.jboss.weld.integration.ejb.SessionBeanInterceptor.beanManager: MyWAR not bound > at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:102) [:2.0.2-FCS] -- 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

15 years, 4 months

1
0
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

15 years, 4 months

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

15 years, 4 months

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

15 years, 4 months

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