July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8595) Thread Pooling configuration from jmx-console doesn't update WorkerStack size. Size remains 200 always.

by Nishant Parikh (JIRA)

Thread Pooling configuration from jmx-console doesn't update WorkerStack size. Size remains 200 always. ------------------------------------------------------------------------------------------------------- Key: JBAS-8595 URL: https://jira.jboss.org/browse/JBAS-8595 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX/Web Console Affects Versions: JBossAS-5.0.1.GA Environment: Windows/Linux, JDK1.5, RAM 2GB, Processor 3GHz, Intel Core Due CPU Reporter: Nishant Parikh Assignee: Darran Lofthouse Priority: Critical When we fire concurrent request more than 200, let's say 200+x (With maxThreads specified 1000 from jmx/web console), Everything works fine but after few seconds x NUMBER OF THREADS GETS BUSY and they never get free. On server log we are getting below ArrayIndexOutOfBoundsException. Exception in thread "http-192.168.1.166-8080-4" java.lang.ArrayIndexOutOfBoundsException: 200 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.push(JIoEndpoint.java:769) at org.apache.tomcat.util.net.JIoEndpoint.recycleWorkerThread(JIoEndpoint.java:724) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:457) at java.lang.Thread.run(Thread.java:662) Exception in thread "http-192.168.1.166-8080-16" java.lang.ArrayIndexOutOfBoundsException: 201 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.push(JIoEndpoint.java:769) at org.apache.tomcat.util.net.JIoEndpoint.recycleWorkerThread(JIoEndpoint.java:724) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:457) at java.lang.Thread.run(Thread.java:662) Exception in thread "http-192.168.1.166-8080-91" java.lang.ArrayIndexOutOfBoundsException: 202 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.push(JIoEndpoint.java:769) at org.apache.tomcat.util.net.JIoEndpoint.recycleWorkerThread(JIoEndpoint.java:724) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:457) at java.lang.Thread.run(Thread.java:662) Exception in thread "http-192.168.1.166-8080-98" java.lang.ArrayIndexOutOfBoundsException: 203 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.push(JIoEndpoint.java:769) at org.apache.tomcat.util.net.JIoEndpoint.recycleWorkerThread(JIoEndpoint.java:724) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:457) at java.lang.Thread.run(Thread.java:662) 17:08:49,515 ERROR [JIoEndpoint] Error allocating socket processor java.lang.ArrayIndexOutOfBoundsException: 203 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.pop(JIoEndpoint.java:778) at org.apache.tomcat.util.net.JIoEndpoint.createWorkerThread(JIoEndpoint.java:661) at org.apache.tomcat.util.net.JIoEndpoint.getWorkerThread(JIoEndpoint.java:702) at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:737) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:313) at java.lang.Thread.run(Thread.java:662) 17:08:49,530 ERROR [JIoEndpoint] Error allocating socket processor java.lang.ArrayIndexOutOfBoundsException: 202 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.pop(JIoEndpoint.java:778) at org.apache.tomcat.util.net.JIoEndpoint.createWorkerThread(JIoEndpoint.java:661) at org.apache.tomcat.util.net.JIoEndpoint.getWorkerThread(JIoEndpoint.java:702) at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:737) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:313) at java.lang.Thread.run(Thread.java:662) 17:08:49,546 ERROR [JIoEndpoint] Error allocating socket processor java.lang.ArrayIndexOutOfBoundsException: 201 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.pop(JIoEndpoint.java:778) at org.apache.tomcat.util.net.JIoEndpoint.createWorkerThread(JIoEndpoint.java:661) at org.apache.tomcat.util.net.JIoEndpoint.getWorkerThread(JIoEndpoint.java:702) at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:737) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:313) at java.lang.Thread.run(Thread.java:662) 17:08:49,548 ERROR [JIoEndpoint] Error allocating socket processor java.lang.ArrayIndexOutOfBoundsException: 200 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.pop(JIoEndpoint.java:778) at org.apache.tomcat.util.net.JIoEndpoint.createWorkerThread(JIoEndpoint.java:661) at org.apache.tomcat.util.net.JIoEndpoint.getWorkerThread(JIoEndpoint.java:702) at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:737) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:313) at java.lang.Thread.run(Thread.java:662) -- 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, 8 months

4
5
0 / 0

[JBoss JIRA] Created: (AS7-829) make-pristine.sh to reset an AS installation to factory settings

by Bob McWhirter (JIRA)

make-pristine.sh to reset an AS installation to factory settings ---------------------------------------------------------------- Key: AS7-829 URL: https://issues.jboss.org/browse/AS7-829 Project: Application Server 7 Issue Type: Enhancement Reporter: Bob McWhirter Assignee: Jason Greene Not sure how this is better than unzip -q jboss-as-bin.zip, but being able to "reset" the domain and such (and bootstrap logging props) to out-of-the-box settings might be nice. Perhaps a separate script to clean the deployments and content repo. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

4
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1744) Create an ivy resolver for maven uniquely versioned snapshots

by Carlo de Wolf (JIRA)

Create an ivy resolver for maven uniquely versioned snapshots ------------------------------------------------------------- Key: EJBTHREE-1744 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1744 Project: EJB 3.0 Issue Type: Feature Request 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, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2464) Unexpected test failures on IBM JDK 6

by Lukáš Petrovický (JIRA)

Unexpected test failures on IBM JDK 6 ------------------------------------- Key: JBRULES-2464 URL: https://jira.jboss.org/jira/browse/JBRULES-2464 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core, drools-testing Reporter: Lukáš Petrovický Assignee: Mark Proctor See BRMS-287. -- 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, 9 months

3
13
0 / 0

[JBoss JIRA] Created: (JBAS-8366) Failure to deploy a war file with JBoss 5.0

by Sasha Matison (JIRA)

Failure to deploy a war file with JBoss 5.0 ------------------------------------------- Key: JBAS-8366 URL: https://jira.jboss.org/browse/JBAS-8366 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-5.0.0.GA Environment: Windows 2003 R2 SP2, JBoss AS 5.0, JDK 1.6_16 Reporter: Sasha Matison Assignee: Scott M Stark Priority: Blocker While deploying our war file with JBoss AS 5.0 we are getting the following error: org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser We are shipping the product with a version of Xerces-j 2.9.1. Removing this version from the product is not an option. Note that the war file used to work with JBoss 4.x. This issue is blocking JBoss 5.0 testing. Please advise on the solution. -- 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, 9 months

4
5
0 / 0

[JBoss JIRA] Created: (JBRULES-3035) Check against duplicate declaration for variable has disappeared

by Wolfgang Laun (JIRA)

Check against duplicate declaration for variable has disappeared ---------------------------------------------------------------- Key: JBRULES-3035 URL: https://issues.jboss.org/browse/JBRULES-3035 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Wolfgang Laun Assignee: Mark Proctor Priority: Critical query locateFacts( int v ) $f: Fact( v: val ) ### this should cause a compile-time error end rule findFact when Fact( $k: key, $k: name ) ### this should cause a compile-time error then end -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

6
13
0 / 0

[JBoss JIRA] Created: (JBRULES-2372) Task - User ReceivedTime whenever Claim operation happens

by vijpan (JIRA)

Task - User ReceivedTime whenever Claim operation happens --------------------------------------------------------- Key: JBRULES-2372 URL: https://jira.jboss.org/jira/browse/JBRULES-2372 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-process-task Affects Versions: 5.1.0.M1 Reporter: vijpan Assignee: Mark Proctor Hi, Is there a way possible where "Received Time" can be stored at Task level. This datetime value should get updated with the current timestamp whenever "Claim" operation happens on the Task. The use case is that most of the time if its a 1 potential owner of the task - the task goes through "created/ready/reserved" status whenever a new Task gets created, in this case creation time would be same as received time --- but whenever the task is assigned to group or multiple potential owner or even when it is in reserved status it can be forwarded/delegated to other user/group - then in that case whenever user receives as task or in WSHT tem claim operation happens can we store the timestamp at the task level. Currently at task level we have creation time/activation time/expiration time ---- may be activation time can be used but i guess its use is very specific as detailed in WSHT/BPEL4People spec. In real world scenario it becomes quite important that when the user actually claimed the task or was assigned the task. Vijay -- 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, 9 months

5
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2749) Various rules stop firing when adding more, totally unrelated rules to a knowledge base

by Ansgar Konermann (JIRA)

Various rules stop firing when adding more, totally unrelated rules to a knowledge base --------------------------------------------------------------------------------------- Key: JBRULES-2749 URL: https://jira.jboss.org/browse/JBRULES-2749 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert), drools-core (expert) Affects Versions: 5.1.1.FINAL Environment: Environment 1: Fedora Core 12 x86_64, Sun JVM 1.6.0_20 64-bit Server VM Environment 2: Windows XP Professional, Service Pack 3, 32 bit; Sun JVM 1.6.0_20 32-bit Server VM Reporter: Ansgar Konermann Assignee: Mark Proctor A certain rule suddenly stops firing when adding more and more rules to the knowledge base, which (not only?) on first sight have *nothing* to do with the rule in question. We created a few unit tests which show the faulty behaviour. What we observed so far: * when using declared functions plus declared data types, this error occurrs. * sometimes, one can work around this problem by renaming a package. We're not sure if this is a reliable workaround, i. e. works in all situations. * one can work around this problem by not using declared functions. We're not sure if this is a reliable workaround. Find attached a ZIPed git repository containing: * a Maven 2.1+ pom.xml suitable to trigger the unit tests via mvn test * Java source files for a TestNG-based unit test * example drools source files to illustrate the problem (used by the unit tests) Please have a look at java file RuleDoesNotFireIfUsingDeclaredFunctionAndTooManyPackages.java. This should make quite clear what we're expecting of the drools library and where it fails to fulfil these expectations. -- 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, 9 months

5
16
0 / 0

[JBoss JIRA] Created: (JBASPECT-29) Aspects Security Unit Tests

by Anil Saldhana (JIRA)

Aspects Security Unit Tests --------------------------- Key: JBASPECT-29 URL: https://jira.jboss.org/jira/browse/JBASPECT-29 Project: JBoss Aspects Issue Type: Task Components: security Reporter: Anil Saldhana Assignee: Anil Saldhana Since aspects security has been given to me based on merit, I am jittery ever since we moved it out as an external project. The unit tests are in the AS test suite. There is a need to have some unit tests for aspects security such that a change happens in aspects security, other projects (ejb3, profile services etc) do not get affected, due to regression. -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated

by Galder Zamarreno (JIRA)

Discrepancies between removing a bean in cache vs bean passivated ----------------------------------------------------------------- Key: EJBTHREE-1500 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1500 Project: EJB 3.0 Issue Type: Sub-task Affects Versions: AS 4.2.3.GA, AS 5.0.0.CR1 Reporter: Galder Zamarreno Assignee: Galder Zamarreno There's a discrepancy between removing a bean from the cache after a timeout when bean is in cache compared to when bean is passivated: Example, when bean is in cache and has to be removed, this is called: if (now - centry.lastUsed >= removalTimeout * 1000) { synchronized (centry) { it.remove(); } } Now, when bean is passivated, this is called: if (now - centry.lastUsed >= removalTimeout * 1000) { get(centry.getId(), false); remove(centry.getId()); } And remove() method calls: if(log.isTraceEnabled()) { log.trace("Removing context " + key); } StatefulBeanContext ctx = null; synchronized (cacheMap) { ctx = (StatefulBeanContext) cacheMap.get(key); } if(ctx == null) throw new NoSuchEJBException("Could not find Stateful bean: " + key); if (!ctx.isRemoved()) container.destroy(ctx); ++removeCount; if (ctx.getCanRemoveFromCache()) { synchronized (cacheMap) { cacheMap.remove(key); } } What this means is that when a bean in cache is removed: 1.- removeCount is not updated 2.- container.destroy(ctx); is not executed and hence the @Remove method is not executed either. -- 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, 9 months

4
7
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2011