June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4507) Out of Memory leads to 1500+ uil2 related threads

by Philippe Ignace (JIRA)

Out of Memory leads to 1500+ uil2 related threads ------------------------------------------------- Key: JBAS-4507 URL: http://jira.jboss.com/jira/browse/JBAS-4507 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.0.3 SP1 Environment: Linux 2.6.9.34 (RedHat) JVM BEA JRocjkit 1.5.0-06, Using IntegrationWithWebSphereMQSeries Reporter: Philippe Ignace Assigned To: Adrian Brock The applications (.EAR with JMS, MDB, jBPM) ends up with an out of memory error and 2000 threads (with 1500 thread related to uil2 according to thread dump). The occurence seams to be related to a high usage of the Webspher MQSeries "gateway". -- 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

19 years, 1 month

2
1
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-287) RemotingTest.testConnectionListener() invalid

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ] Tim Fox closed JBMESSAGING-287. ------------------------------- Resolution: Done Assignee: Tim Fox Ron's advice: Try replacing Client client = new Client(serverLocator); with HashMap metadata = new HashMap(); metadata.put(InvokerLocator.FORCE_REMOTE, "true"); metadata.put(Client.ENABLE_LEASE, "true"); Client client = new Client(serverLocator, metadata); Without the FORCE_REMOTE parameter, LocalClientInvoker gets used, in which case leasing is disabled, since it's pointless. And ENABLE_LEASE tells Client to negotiate a lease with the server. Instead of metadata, it could go in the InvokerLocator, or, equivalently, it could be an attribute in the remoting-service.xml file with "isParam=true". Now the test passes > RemotingTest.testConnectionListener() invalid > --------------------------------------------- > > Key: JBMESSAGING-287 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287 > Project: JBoss Messaging > Issue Type: Bug > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Priority: Minor > Fix For: 1.4.0.CR1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. > After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. -- 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

19 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-640) Eliminate duplication of deployment descriptors across repositories (Messaging and AS)

by Ovidiu Feodorov (JIRA)

Eliminate duplication of deployment descriptors across repositories (Messaging and AS) -------------------------------------------------------------------------------------- Key: JBMESSAGING-640 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-640 Project: JBoss Messaging Issue Type: Sub-task Components: Build System Affects Versions: 1.2.0.Alpha2, 1.0.1.GA Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.CR1 To quickly complete integration with JBAS5, I've copied JBoss-specific deployment descriptors accross repositories. remoting-service.xml, connection-factories-service.xml, messaging-service.xml, hsqldb-persistence-service.xml, destinations-service.xml, jms-ds.xml, as well as messaging-users.properties and messaging-roles.properties are duplicated in both https://svn.jboss.org/repos/messaging/src/etc/server/default/deploy and https://svn.jboss.org/repos/jbossas/messaging/src/etc/deploy. Find a solution that would allow maintaining only one copy (SVN links?) -- 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

19 years, 1 month

4
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-1114) StackOverflowError with Glassfish TransactionManager

by Brian Stansberry (JIRA)

StackOverflowError with Glassfish TransactionManager ---------------------------------------------------- Key: JBCACHE-1114 URL: http://jira.jboss.com/jira/browse/JBCACHE-1114 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP3, 2.0.0.CR2 Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.0.0.CR3, 1.4.1.SP4 Problem is Glassfish's Transaction impl includes any registered Synchronization in its toString() output. And then OrderedSynchronizationHandler.toString includes the Transaction in its ouput. Endless loop. java.lang.RuntimeException: java.lang.StackOverflowError at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5875) at org.jboss.cache.TreeCache._replicate(TreeCache.java:5162) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:650) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:535) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:358) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:775) at org.jgroups.JChannel.up(JChannel.java:1091) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:377) at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:393) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158) at org.jgroups.stack.UpHandler.run(Protocol.java:60) Caused by: java.lang.StackOverflowError at java.lang.String.valueOf(String.java:2615) at java.lang.StringBuffer.append(StringBuffer.java:220) at org.jboss.cache.interceptors.OrderedSynchronizationHandler.toString(OrderedSynchronizationHandler.java:96) at java.lang.String.valueOf(String.java:2615) at java.util.AbstractCollection.toString(AbstractCollection.java:454) at java.util.Vector.toString(Vector.java:946) at java.lang.String.valueOf(String.java:2615) at java.lang.StringBuilder.append(StringBuilder.java:116) at com.sun.enterprise.distributedtx.J2EETransaction.toString(J2EETransaction.java:602) at java.lang.String.valueOf(String.java:2615) at java.lang.StringBuffer.append(StringBuffer.java:220) Possible solution is for OrderedSynchronizationHandler (and any other JBC Synchronization impl) to not call toString() on the tx, but rather build a String from the classname and the system identity hashcode. -- 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

19 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1090) Emit JMX Notifications the JBAS JSR-77 layer expects

by Brian Stansberry (JIRA)

Emit JMX Notifications the JBAS JSR-77 layer expects ---------------------------------------------------- Key: JBCACHE-1090 URL: http://jira.jboss.com/jira/browse/JBCACHE-1090 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.0.0.CR3 JBAS listens for JMX notifications conforming to the types emitted by the AS ServiceMBeanSupport subclasses. Uses them to update the JSR-77 state information for services. The JMX wrappers might as well emit these events as well. Only negative is the names of the events include AS packages, but who cares, they're just strings. -- 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

19 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-854) JMX Management rationalization

by Brian Stansberry (JIRA)

JMX Management rationalization ------------------------------ Key: JBCACHE-854 URL: http://jira.jboss.com/jira/browse/JBCACHE-854 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.GA In 2.0 JBC no longer inherits from the AS's ServiceMBeanSupport class, and JMX registration is handled differently. This is a parent task for sorting out issues related to JMX in this new environment. -- 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

19 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1517) Dashboard configuration page duplicated content

by Chris Laprun (JIRA)

Dashboard configuration page duplicated content ----------------------------------------------- Key: JBPORTAL-1517 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1517 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6 Final Reporter: Chris Laprun Fix For: 2.6.1 Final Attachments: Picture 1.png See attached screenshot. -- 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

19 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-4443) Remove deprecated HAPartition methods

by Brian Stansberry (JIRA)

Remove deprecated HAPartition methods ------------------------------------- Key: JBAS-4443 URL: http://jira.jboss.com/jira/browse/JBAS-4443 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta3 A couple overloaded methods for doing RPCs in HAPartition have been deprecated at least since 4.0.0. Remove them. -- 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

19 years, 1 month

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-954) '==' & '!=' not working properly with globals

by Brian Enderle (JIRA)

'==' & '!=' not working properly with globals --------------------------------------------- Key: JBRULES-954 URL: http://jira.jboss.com/jira/browse/JBRULES-954 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.MR3 Environment: Windows XP, Drools MR3 Reporter: Brian Enderle Assigned To: Mark Proctor The equality operators (== & !=) are not working correctly when comparing a value to a global. This holds true for globals of the type java.lang.Character and java.lang.String. Given: Person object with sex set to 'M' rule "Must be male" when $p : Person ( sex == 'M' ) then System.out.println ( "- This is a man" ); end rule "Cannot be a man" when $p : Person ( sex != 'M') then System.out.println ( "- This must be a woman") end Results: - This is a man If we replace the 'M' with the global "maleCode" and set it to 'M' in our calling program then, gloabl java.lang.Character maleCode; rule "Must be male" when $p : Person ( sex == maleCode ) then System.out.println ( "- This is a man" ); end rule "Cannot be a man" when $p : Person ( sex != maleCode) then System.out.println ( "- This must be a woman") end Results: - This is a man - This must be a woman Both rules are passing when one, the latter, should fail Brian Enderle -- 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

19 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-953) memberOf and not memberOf not working

by Brian Enderle (JIRA)

memberOf and not memberOf not working ------------------------------------- Key: JBRULES-953 URL: http://jira.jboss.com/jira/browse/JBRULES-953 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.MR3 Environment: Windows XP, Drools MR3 Reporter: Brian Enderle Assigned To: Mark Proctor The use of "memberOf" and "not memberOf" does not appear to do anything as it always evaluates to true. Example: given an Address object with countryCd of "US" & List of country codes of {"US", "MX" and "CA"} rule "Country must be US, MX or CA" when $i : Address( countryCd != null, countryCd not memberOf countryCodes, $countryCd : countryCd ) then System.out.println("- Country must be US, MX or CA"); end rule "Country must not be US, MX or CA" when $i : Address( countryCd != null, countryCd memberOf countryCodes, $countryCd : countryCd ) then System.out.println("- Country must not be US, MX or CA"); end The results of these two rules is the following: - Country must be US, MX or CA - Country must not be US, MX or CA One of these should not fire, in this case the first rule should not evaluate to true and therefore should not fire. Brian Enderle -- 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

19 years, 1 month

2
2
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 June 2007