July 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-3569) Avoid JITting constraint if the used PermGen size is above a given threshold

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3569: ------------------------------------ Summary: Avoid JITting constraint if the used PermGen size is above a given threshold Key: JBRULES-3569 URL: https://issues.jboss.org/browse/JBRULES-3569 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco JITting all the constraints used in a large rule base can cause an OutOfMemory error in the PermGen space. Before to JIT a constraint it is necessary to check if the PermGen space currently in use is above a (optionally configurable) threshold and in this case avoid the JITting and let the constraint to be evaluated in interpreted mode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
1
0 / 0

[JBoss JIRA] (JBRULES-3548) Easy version bumping during release procedure: Fix script update-version-all.sh

by Geoffrey De Smet (JIRA)

13 years, 10 months

2
5
0 / 0

[JBoss JIRA] (AS7-5122) It is not possible enable a datasource via CLI if enabled attribute is not present in xml

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/AS7-5122?page=com.atlassian.jira.plugin.s... ] Stefano Maestri moved JBPAPP-9453 to AS7-5122: ---------------------------------------------- Project: Application Server 7 (was: JBoss Enterprise Application Platform) Key: AS7-5122 (was: JBPAPP-9453) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: (was: EAP 6.0.0 (CR1)) Component/s: JCA (was: JCA) Security: (was: Public) Docs QE Status: (was: NEW) > It is not possible enable a datasource via CLI if enabled attribute is not present in xml > ----------------------------------------------------------------------------------------- > > Key: AS7-5122 > URL: https://issues.jboss.org/browse/AS7-5122 > Project: Application Server 7 > Issue Type: Bug > Components: JCA > Environment: JBoss-EAP6-Beta2 > Reporter: Tyronne Wickramarathne > Assignee: Stefano Maestri > Labels: cli > > It's not possible to enable a datasource via CLI. The following exception gets thrown : > JBAS014749: Operation handler failed: Service jboss.data-source-config.ExampleDS is already registered -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-4397) console uses relative paths for redirections

by Aleksandar Kostadinov (JIRA)

Aleksandar Kostadinov created AS7-4397: ------------------------------------------ Summary: console uses relative paths for redirections Key: AS7-4397 URL: https://issues.jboss.org/browse/AS7-4397 Project: Application Server 7 Issue Type: Bug Components: Console Affects Versions: 7.1.1.Final Reporter: Aleksandar Kostadinov Assignee: Heiko Braun Console uses relative address in Location header when redirecting: $ curl -v localhost:9990 * About to connect() to localhost port 9990 (#0) * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 9990 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2 > Host: localhost:9990 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Transfer-encoding: chunked < Location: /console/index.html < Date: Wed, 04 Apr 2012 12:50:14 GMT < * Connection #0 to host localhost left intact * Closing connection #0 This is a problem running a reverse proxy to server the console. RFC 1945 requires that to be a complete absolute URI [1]. The problem is that mod_proxy expects a complete URI. The problem manifests when proxying is performed on path other than ROOT of the http server (e.g. you open http://server_public_hostname/asconsole to access console). A typical mod_proxy configuration in this case would be: ProxyPass /asconsole/ http://localhost:9990/ ProxyPassReverse /asconsole/ http://localhost:9990/ ProxyPassReverseCookiePath / /asconsole/ ProxyPassReverseCookieDomain localhost server_public_hostname redirects in this case are not translated by mod_proxy because it matches against string "http://localhost:9990/". And one is redirected to /something instead of /asconsole/something. curl output: curl -v http://my_public_hostname/asconsole * About to connect() to my_public_hostname port 80 (#0) * Trying 24.24.164.76... connected * Connected to my_public_hostname (24.24.164.76) port 80 (#0) > GET /asconsole HTTP/1.1 > User-Agent: curl/7.21.0 (i486-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6 > Host: my_public_hostname > Accept: */* > < HTTP/1.1 301 Moved Permanently < Date: Wed, 04 Apr 2012 12:29:30 GMT < Location: /console/index.html < Connection: close < Transfer-Encoding: chunked < Content-Type: text/plain; charset=UTF-8 < * Closing connection #0 The workarounds are described in the workaround section. I'm not really sure what the best approach for this problem would be. Using the Host header of request makes some sense but if one already uses ProxyPreserveHost On then it can also affect this functionality. Hardcoding the URL would be a complication to configuration. Perhaps making the behavior configurable and documented would be best. [1] http://en.wikipedia.org/wiki/HTTP_location -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
10
0 / 0

[JBoss JIRA] Created: (JBAS-8390) Allow for configuration of respawn policy in host.xml/domain.xml

by Kabir Khan (JIRA)

Allow for configuration of respawn policy in host.xml/domain.xml ---------------------------------------------------------------- Key: JBAS-8390 URL: https://jira.jboss.org/browse/JBAS-8390 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Fix For: 7.0.0.M1 The server manager currently uses the default respawn policy -- 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

13 years, 10 months

4
6
0 / 0

[JBoss JIRA] (AS7-5121) Refactor messaging transport configuration

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-5121: -------------------------------- Summary: Refactor messaging transport configuration Key: AS7-5121 URL: https://issues.jboss.org/browse/AS7-5121 Project: Application Server 7 Issue Type: Task Components: JMS Affects Versions: 7.1.2.Final (EAP) Reporter: Jeff Mesnil Assignee: Jeff Mesnil Priority: Minor The messaging subsystems defines transport parameters for generic/in-vm/remote connectors & acceptors. The code needs to be refactored to leverage the management API and removes the complexities in TransportConfigHandlers, TransportParamDefinition. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-3972) Review module name of remotingjmx

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-3972: ------------------------------------- Summary: Review module name of remotingjmx Key: AS7-3972 URL: https://issues.jboss.org/browse/AS7-3972 Project: Application Server 7 Issue Type: Task Components: JMX Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.1.1.Final Current module should be retained for backwards compatibility. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
3
0 / 0

[JBoss JIRA] (JGRP-1486) Merge failure when dead instances remain in view

by David Hotham (JIRA)

David Hotham created JGRP-1486: ---------------------------------- Summary: Merge failure when dead instances remain in view Key: JGRP-1486 URL: https://issues.jboss.org/browse/JGRP-1486 Project: JGroups Issue Type: Bug Affects Versions: 3.0.10 Reporter: David Hotham Assignee: Bela Ban I've hit this testing my JGRP-1485 fix, but I think it's a logically independent issue. So, I've reached a point where: - A, B and C all have view {C,A,B} - D has view {B', D', D, A', C}, in which B', D' and A' are all dead instances As in JGRP-1485, an optimal fix would surely be to allow D to recover all by itself, but it's not clear to me how to do that. However, my expectation was that a merge should sort things out; and I think that if it did then that ought to be good enough. But what's actually happening is this: - C becomes merge leader - determines that merge participants are C, D', D, A' - sends MERGE_REQ to those members - the MERGE_REQ to D' reaches D (and that to A' reaches A) - D sends a positive response for the MERGE_REQ that was meant for it, but after 2.5 seconds also sends a negative response to the MERGE_REQ meant for D'. (I think that the negative response is because it can't fetch the digest from D') - likewise A sends a negative response to the MERGE_REQ meant for A' So what C sees is: - good responses from C and D, followed by merge_rejected responses from A and D - so it removes A' and D' from the merge (it didn't get responses from them) - then it removes D from the merge (because the most recent response from D said merge_rejected) - so it is left only with itself, and comes up with a consolidated view that is identical to its original view in short: the merge doesn't do anything useful after all. I think that the key here is the confusion between D and D'. Possibly the fix is as simple as: ignore MERGE_REQs where the destination address on the message is not the local address. I'll try this out and, if it looks good, submit a pull request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
6
0 / 0

[JBoss JIRA] (AS7-5119) JMS Bridge service is started before JMS resources are deployed in JNDI

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-5119: -------------------------------- Summary: JMS Bridge service is started before JMS resources are deployed in JNDI Key: AS7-5119 URL: https://issues.jboss.org/browse/AS7-5119 Project: Application Server 7 Issue Type: Bug Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 7.2.0.Alpha1 Steps to reproduce: 1. add a <jms-bridge> to standalone-full.xml which depends on local JMS resources for its source or target destinations 2. start the AS7 instance => a stack trace is displayed because the JMS bridge is started before the JMS resources are available in the JNDI tree {code} 08:45:59,638 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-1) HornetQ Server version 2.2.18.Final (HQ_2_2_18_FINAL, 122) [166a8a18-c5ec-11e1-b6e6-616f49f3825a]) started 08:45:59,641 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 63) trying to deploy queue jms.queue.sourceQueue 08:45:59,644 WARNING [org.hornetq.jms.bridge.impl.JMSBridgeImpl] (ServerService Thread Pool -- 61) Failed to connect bridge: javax.naming.NameNotFoundException: queue/sourceQueue -- service jboss.naming.context.java.queue.sourceQueue at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:97) [jboss-as-naming-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [jboss-as-naming-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:119) [jboss-as-naming-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:215) [jboss-as-naming-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_03-icedtea] at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:58) [hornetq-jms-2.2.18.Final.jar:2.2.18.Final (HQ_2_2_18_FINAL, 122)] at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40) [hornetq-jms-2.2.18.Final.jar:2.2.18.Final (HQ_2_2_18_FINAL, 122)] at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1124) [hornetq-jms-2.2.18.Final.jar:2.2.18.Final (HQ_2_2_18_FINAL, 122)] at org.hornetq.jms.bridge.impl.JMSBridgeImpl.start(JMSBridgeImpl.java:358) [hornetq-jms-2.2.18.Final.jar:2.2.18.Final (HQ_2_2_18_FINAL, 122)] at org.jboss.as.messaging.jms.bridge.JMSBridgeService.startBridge(JMSBridgeService.java:92) [jboss-as-messaging-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] at org.jboss.as.messaging.jms.bridge.JMSBridgeService$1.run(JMSBridgeService.java:78) [jboss-as-messaging-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_03-icedtea] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_03-icedtea] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03-icedtea] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] 08:45:59,649 WARNING [org.hornetq.jms.bridge.impl.JMSBridgeImpl] (ServerService Thread Pool -- 61) Failed to start bridge {code} The JMS Bridge service has a dependency on the HornetQ service when one of its resources (source or target) is local but the JMS resources are bound to JNDI asynchronously *after* the HornetQ server is started. The JMS bridge service should instead check whether its JMS resources are local or not. If they are local, it should add a direct dependency to the corresponding binder service (for both destination and CF resource) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5118) REGRESSION: JBoss 7 cannot process JBossXB in timer schedules

by Richard Kennard (JIRA)

Richard Kennard created AS7-5118: ------------------------------------ Summary: REGRESSION: JBoss 7 cannot process JBossXB in timer schedules Key: AS7-5118 URL: https://issues.jboss.org/browse/AS7-5118 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.1.Final Reporter: Richard Kennard Assignee: Jason Greene In JBoss AS 6, you could use 'JBossXB expressions' (sorry if that's the wrong terminology, I couldn't find much documentation on this) in ejb-jar.xml to configure timer schedules: <session> <ejb-name>Foo</ejb-name> <timer> <schedule> <minute>*/${how.often:10}</minute> <hour>*</hour> </schedule> The idea here is that 'minute' would default to 10, unless you passed -Dhow.often=5 as a VM arg. This worked under AS 6, but under 7.1.1.Final you get: Caused by: java.lang.NumberFormatException: For input string: "${how.often:10}" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) [rt.jar:1.6.0_24] at java.lang.Integer.parseInt(Integer.java:449) [rt.jar:1.6.0_24] at java.lang.Integer.parseInt(Integer.java:499) [rt.jar:1.6.0_24] at org.jboss.as.ejb3.timerservice.schedule.attribute.IntegerBasedExpression.parseInt(IntegerBasedExpression.java:199) at org.jboss.as.ejb3.timerservice.schedule.attribute.IntegerBasedExpression.processIncrement(IntegerBasedExpression.java:174) at org.jboss.as.ejb3.timerservice.schedule.attribute.IntegerBasedExpression.<init>(IntegerBasedExpression.java:87) at org.jboss.as.ejb3.timerservice.schedule.attribute.Minute.<init>(Minute.java:74) at org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.<init>(CalendarBasedTimeout.java:126) at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createCalendarTimer(TimerServiceImpl.java:477) at org.jboss.as.ejb3.timerservice.TimerServiceImpl.loadAutoTimer(TimerServiceImpl.java:360) at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:681) at org.jboss.as.ejb3.timerservice.TimerServiceImpl.start(TimerServiceImpl.java:190) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
4
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 July 2012