February 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender

by Bela Ban (JIRA)

Optimization: make threads return immediately if NAKACK has another active thread for the same sender ----------------------------------------------------------------------------------------------------- Key: JGRP-457 URL: http://jira.jboss.com/jira/browse/JGRP-457 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up. If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock. The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

5 days, 13 hours

2
3
0 / 0

[JBoss JIRA] (AS7-3751) Change the default object store of JBoss transactions to use the hornetq object store

by Tom Jenkinson (JIRA)

Tom Jenkinson created AS7-3751: ---------------------------------- Summary: Change the default object store of JBoss transactions to use the hornetq object store Key: AS7-3751 URL: https://issues.jboss.org/browse/AS7-3751 Project: Application Server 7 Issue Type: Feature Request Components: Transactions Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: Open To Community This would provide a performance boost, however it is not supportable until AS7-925 is complete as the object store cannot be manipulated on the filesystem to resolve heuristics, tooling is necessary. PS Do not implement this feature without tooling or discussing with me, I will add this after tooling is added. -- 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

12 years, 10 months

1
1
0 / 0

[JBoss JIRA] (AS7-3834) Socket bind for JIoEndpoint fails on shutdown when using link-local IPv6 address

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created AS7-3834: ---------------------------------------- Summary: Socket bind for JIoEndpoint fails on shutdown when using link-local IPv6 address Key: AS7-3834 URL: https://issues.jboss.org/browse/AS7-3834 Project: Application Server 7 Issue Type: Bug Components: Web Affects Versions: 7.1.0.Final Reporter: Richard Achmatowicz Assignee: Mladen Turk Start AS 7.1.0.Final with a link local IPv6 address: {noformat} [nrla@lenovo ~]$ /sbin/ifconfig eth0 Link encap:Ethernet HWaddr F0:DE:F1:40:75:B8 inet addr:192.168.0.103 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::f2de:f1ff:fe40:75b8/64 Scope:Link inet6 addr: 3ffe:ffff:100:f101::1/64 Scope:Global [nrla@lenovo ~]$ ./standalone.sh -Djboss.bind.address=fe80::f2de:f1ff:fe40:75b8 -Djboss.bind.address.management=fe80::f2de:f1ff:fe40:75b8 {noformat} and the following exception occurs: {noformat} 11:01:28,909 INFO [org.jboss.as.remoting] (MSC service thread 1-7) JBAS017100: Listening on /fe80:0:0:0:f2de:f1ff:fe40:75b8:4447 11:01:29,013 INFO [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-1) JBoss Web Services - Stack CXF Server 4.0.1.GA 11:01:29,185 ERROR [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-6) Error initializing endpoint: java.lang.Exception: Socket bind failed: [22] Invalid argument at org.apache.tomcat.util.net.AprEndpoint.init(AprEndpoint.java:578) [jbossweb-7.0.10.Final.jar:] at org.apache.coyote.http11.Http11AprProtocol.init(Http11AprProtocol.java:121) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.0.10.Final.jar:] at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:267) [jboss-as-web-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT] 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] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26] 11:01:29,254 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.web.connector.http: org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:271) 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] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26] Caused by: LifecycleException: Protocol handler initialization failed: java.lang.Exception: Socket bind failed: [22] Invalid argument at org.apache.catalina.connector.Connector.init(Connector.java:985) at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:267) ... 5 more 11:01:29,442 INFO [org.jboss.as.remoting] (MSC service thread 1-7) JBAS017100: Listening on /fe80:0:0:0:f2de:f1ff:fe40:75b8:9999 11:01:29,462 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) JBAS015012: Started FileSystemDeploymentService for directory /home/nrla/projects/jboss-as/build/target/jboss-as-7.1.0.Final-SNAPSHOT/standalone/deployments 11:01:29,615 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS] 11:01:29,626 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report JBAS014777: Services which failed to start: service jboss.web.connector.http: org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector 11:01:29,649 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.1.0.Final-SNAPSHOT "Flux Capacitor" started (with errors) in 2317ms - Started 133 of 203 services (1 services failed or missing dependencies, 68 services are passive or on-demand) {noformat} I had a look around and found this related (in fact the same) bug report: https://issues.apache.org/bugzilla/show_bug.cgi?id=43327 Looks like it may have been fixed for IPv6 addresses other than link-local. Link-local addresses are used often for running on a local network segment. -- 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

12 years, 10 months

7
27
0 / 0

[JBoss JIRA] Created: (AS7-1534) Ability to use alternate persistent stores for EJB timers

by Stuart Douglas (JIRA)

Ability to use alternate persistent stores for EJB timers --------------------------------------------------------- Key: AS7-1534 URL: https://issues.jboss.org/browse/AS7-1534 Project: Application Server 7 Issue Type: Feature Request Components: EJB Affects Versions: 7.0.1.Final Reporter: Stuart Douglas Assignee: Stuart Douglas We need the ability to store persistent timers in a JDBC database -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (RELOADED-8) Create a JSR-250 compliant injection framework on top of VDF

by Carlo de Wolf (JIRA)

Create a JSR-250 compliant injection framework on top of VDF ------------------------------------------------------------ Key: RELOADED-8 URL: https://jira.jboss.org/jira/browse/RELOADED-8 Project: JBoss Reloaded Issue Type: Feature Request Components: injection Affects Versions: injection-0.1.0 Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- 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

12 years, 10 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-7882) Wrong provider code base for security provider included in packed ear

by Petr H (JIRA)

Wrong provider code base for security provider included in packed ear --------------------------------------------------------------------- Key: JBAS-7882 URL: https://jira.jboss.org/jira/browse/JBAS-7882 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: VFS Affects Versions: JBossAS-6.0.0.M2, JBossAS-5.1.0.GA Environment: Any OS, JDK 5 and 6, JBoss AS 5.1.0 and 6.0.0.M2 Reporter: Petr H We've got applications which uses the IAIK JCE provider (http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/JCA-JCE) whose library is included directly in our application. On JBoss AS 5 and later, we can't use this provider as usually. The new VFS mechanism seems to break the path determination to the IAIK provider library (needed to determine provider code base) - it still points into the ear/war structure inside the server deploy directory but as all this is packed into one ear file, the provider verification.fails because of unsigned ear/war and thus the following exception is thrown: 2010-04-01 15:04:20,890 ERROR [STDERR] (http-0.0.0.0-8180-1) java.lang.SecurityException: JCE cannot authenticate the provider IAIK 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at iaik.test.ControllerServlet.service(ControllerServlet.java:123) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:905) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:592) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2036) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at java.lang.Thread.run(Thread.java:619) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) Caused by: java.util.jar.JarException: Cannot parse jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_c.a(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.b(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.a(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) ... 24 more This works when one of tho three mentioned workarounds is used. The most interesting of course is the third workaround for which the code base corectly points to the temporary IAIK library instance in the java.io.tmpdir: 2010-04-01 15:09:51,291 INFO [STDOUT] (http-0.0.0.0-8180-1) Provider code base: file:/tmp/nestedjar2481829661547119990.tmp I'll attach a simple testcase ear (IAIKTest.ear) which contains an evaluation version of IAIK provider library (thanks for permission to the IAIK authors) and a simple servlet (including source) which demonstrates the problem. All you need to do is to have the unrestricted JCE policy files installed in your JRE and then just put the IAIKTest.ear into the deploy directory, start the JBoss instance and access the test servlet URL in browser, for example: http://localhost:8080/IAIKTestWeb/ControllerServlet On init (which happens on start) it will register the IAIK provider On service (after you access it in browser) it will attempt to get some cipher instance and here it fails. I'll also attach two log files covering the problem: - server-default.log with default server setup where the issue occurs - server-forceVfsJar.log with jboss.vfs.forceVfsJar=true where the issue doesn't occur Also I think this is more generic problem because we had similar issues, where some jar or resource location was pointing to the packed ear/war structure inside the deploy directory instead of those VFS temporary locations, with our own code (when attemting to obtain full path) and had to perform some modifications in order to make it working. The same set of workarounds could resolve these issues as well. -- 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

12 years, 10 months

17
51
0 / 0

[JBoss JIRA] Created: (JASSIST-126) create OSGi bundle information

by Mark Struberg (JIRA)

create OSGi bundle information ------------------------------ Key: JASSIST-126 URL: https://jira.jboss.org/browse/JASSIST-126 Project: Javassist Issue Type: Feature Request Affects Versions: 3.12.0.GA Reporter: Mark Struberg Assignee: Shigeru Chiba Fix For: 3.13.0.GA Create OSGi bundle information for javassist at build time. -- 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

12 years, 10 months

5
9
0 / 0

[JBoss JIRA] (AS7-3463) Provide Unit for JVM configuration elements

by Heiko Braun (JIRA)

Heiko Braun created AS7-3463: -------------------------------- Summary: Provide Unit for JVM configuration elements Key: AS7-3463 URL: https://issues.jboss.org/browse/AS7-3463 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management Reporter: Heiko Braun Assignee: Brian Stansberry Fix For: 7.2.0.Alpha1 Like with any other config element, units for the JVM parameters would nice. I.e. instead of encoding it into the string value ("64m") it would be better to split the actual value from unit (value=64, unit=<kb|mb|gb>). See the thread subsystem for a reference how this is done in other places -- 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

12 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAOP-796) Creation of ClassAdvisor must use the AspectManager equivalent to the advised class' ClassLoader

by Flavia Rainone (JIRA)

Creation of ClassAdvisor must use the AspectManager equivalent to the advised class' ClassLoader ------------------------------------------------------------------------------------------------ Key: JBAOP-796 URL: https://jira.jboss.org/browse/JBAOP-796 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.9.Alpha1 Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: 2.1.6 CP01, 2.1.9.GA, 2.2.1.GA Currently, an Advisor is created by calling AspectManager.instance().getAdvisor(). The correct is to create the advisor by calling AspectManager.instance(WovenClass.class).getAdvisor(WovenClass.class). Otherwise, the Advisor will be created as part of the AspectManager/Domain corresponding to the current context class loader: public static synchronized AspectManager instance() { return instance(Thread.currentThread().getContextClassLoader()); } In the JBoss AS environment, if the woven class is loaded during an archive deployment, this is equivalent to say that the Advisor will be erroneously created by the domain of the current deployment, instead of being created by the appropriate AspectManager/Domain instance. -- 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

12 years, 11 months

2
10
0 / 0

[JBoss JIRA] Created: (JBAOP-806) Using UnmodifiableLinkedHashMap constructor causes an UnsupportedOperationException exception to be thrown on IBM JDK

by Dustin Kut Moy Cheung (JIRA)

Using UnmodifiableLinkedHashMap constructor causes an UnsupportedOperationException exception to be thrown on IBM JDK --------------------------------------------------------------------------------------------------------------------- Key: JBAOP-806 URL: https://issues.jboss.org/browse/JBAOP-806 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Components: Aspect Library Environment: OS: Fedora 14 JDK: IBM JDK Reporter: Dustin Kut Moy Cheung Priority: Critical Read Summary. This error is caused because the IBM JDK LinkedHashMap invokes the putAll method on HashMap. Since the putAll method is overwridden in UnmodifiableLinkedHashMap.java, the UnmodifiableLinkedHashMap putAll method is called instead of the HashMap constructor and therefore throws that exception. The fix is to change the signature of the constructor being called (LinkedHashMap constructor) so that the putAll method is not called. Please see the patch that attempts to solve this issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2012