December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-2823) Upgrade commons-logging to Release 1.1.0

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2823?page=all ] Dimitris Andreadis updated JBAS-2823: ------------------------------------- Component/s: Logging Fix Version/s: JBossAS-4.2.0.CR1 Affects: [Compatibility/Configuration] Assignee: Dimitris Andreadis Priority: Major (was: Optional) > Upgrade commons-logging to Release 1.1.0 > ---------------------------------------- > > Key: JBAS-2823 > URL: http://jira.jboss.com/jira/browse/JBAS-2823 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Logging > Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1 > Environment: Windows XP Professional, JDK 1.5.0 > Reporter: Martin Lui > Assigned To: Dimitris Andreadis > Fix For: JBossAS-4.2.0.CR1 > > > The Apache commons-logging package has release version 1.1.0. > Please upgrade this library to take advantage of items listed in the release notes: > http://jakarta.apache.org/commons/logging/RELEASE-NOTES.txt > It would be helpful if this upgrade can be done to upgrade the server libraries since individual EAR files cannot overwrite this particular library. > Also, looking through the notes and searching for information on the 1.0.4 patch, it appears that the WeakHashTables memory-leak fix is included in 1.1.0. (Bug 31286: http://issues.apache.org/bugzilla/show_bug.cgi?id=31286) > Depending on how JBoss uses this package, upgrading should be as simple as replacing the current package (though I admit I had not try doing so yet). -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCLUSTER-99) 4.0.4CR2 under Jbento load test numbers

by Tony Starks (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-99?page=comments#action_12348948 ] Tony Starks commented on JBCLUSTER-99: -------------------------------------- >>2006-03-20 16:05:18,669 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 72.16.130.57:41887, local_addr=172.16.129.57:49802) >>message with seqno=3280 not found in sent_msgs ! sent_msgs=[1477 - 3503] I am having the same problem as above mentioned with JGroups 4rc2(cannot as yet update version to higher). How can i fix it ? Tips on how you resolved the above would be welcome. > 4.0.4CR2 under Jbento load test numbers > --------------------------------------- > > Key: JBCLUSTER-99 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-99 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q2Y6 > > Attachments: ResultsExtract.pdf > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > I have used JBento to perform load test with 2 nodes cluster (dev02, dev03). It only loads dev02 (so not load balanced yet). This is just a simple counter String test. > 1. 10 clients with 10 ms sleep in between. The tps is 85. No error message produced > 2. 50 client with 10ms sleep. Lots of errors: > 2006-03-20 16:05:18,667 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3277 not > found in sent_msgs ! sent_msgs=[1477 - 3502] > 2006-03-20 16:05:18,668 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3278 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > 2006-03-20 16:05:18,668 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3279 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > 2006-03-20 16:05:18,669 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3280 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > The other node also ran into OOM as well. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-3272) update JBossRemoting to version 2.0.0

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3272?page=comments#action_12348947 ] Dimitris Andreadis commented on JBAS-3272: ------------------------------------------ Upgrade to jboss remoting 1.4.5 - maybe we stick we this version for jboss 4.2 after all. > update JBossRemoting to version 2.0.0 > ------------------------------------- > > Key: JBAS-3272 > URL: http://jira.jboss.com/jira/browse/JBAS-3272 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Remoting > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Critical > Fix For: JBossAS-4.2.0.CR1 > > > Need to update JBossAS to include jboss-remoting.jar for version 2.0.0.GA of JBossRemoting. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-104) Re-qualify against MQSeries

by Mark Little (JIRA)

Re-qualify against MQSeries --------------------------- Key: JBESB-104 URL: http://jira.jboss.com/jira/browse/JBESB-104 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: ESB Core Affects Versions: 4.0 Alpha 1 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.0 -- 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, 7 months

2
9
0 / 0

[JBoss JIRA] Created: (JBESB-259) Rename trailblazer2 to trailblazer

by Mark Little (JIRA)

Rename trailblazer2 to trailblazer ---------------------------------- Key: JBESB-259 URL: http://jira.jboss.com/jira/browse/JBESB-259 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Examples Affects Versions: 4.0 RC1 Reporter: Mark Little Assigned To: Daniel Brum Priority: Minor Fix For: 4.0 -- 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, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-262) Service dependency - recover capability. (i.e. Gateways -> Listener dependency)

by Kurt Stam (JIRA)

Service dependency - recover capability. (i.e. Gateways -> Listener dependency) -------------------------------------------------------------------------------- Key: JBESB-262 URL: http://jira.jboss.com/jira/browse/JBESB-262 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: ESB Core Affects Versions: 4.0 RC1 Reporter: Kurt Stam Assigned To: Mark Little Priority: Blocker Fix For: 4.0 When a service depends on a resource that can not be discovered at when the service is coming up, the service should log a warning, sleep for a bit and try again, indefinetly, until the missing resource is found. For example, all gateways depend on a listerner, if the gateway comes up before that listener the current implementation pretty much dies. We should simply put the gateway in a holding pattern. Similarly, if during execution the JMS provider (ftp server, or any other dependency) goes off line, we should not die, but simply log, sleep and retry. A nice to have would be that after an n number of retries we send a notification to a place where JBossON can pick it up and notify someone of a problem, This behavior should be easy to implement, and should take care of the current race condition we experience. -- 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, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (JBESB-233) Message Store access via CBR?

by Mark Little (JIRA)

Message Store access via CBR? ----------------------------- Key: JBESB-233 URL: http://jira.jboss.com/jira/browse/JBESB-233 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ESB Core Reporter: Mark Little Assigned To: Mark Little Fix For: 4.1 Does it make sense to tie the Message Store into the system via CBR, i.e., a CBR dispatcher/handler in each process that routes messages to the store based on specific rules (wildcard support to catch "route all" messages)? -- 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, 7 months

2
3
0 / 0

[JBoss JIRA] Updated: (JBAS-2939) Make Invocation policies more configurable

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2939?page=all ] Dimitris Andreadis updated JBAS-2939: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) Assignee: Tom Elrod > Make Invocation policies more configurable > ------------------------------------------ > > Key: JBAS-2939 > URL: http://jira.jboss.com/jira/browse/JBAS-2939 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Remoting > Reporter: Adrian Brock > Assigned To: Tom Elrod > Fix For: JBossAS-4.2.1.CR1 > > > Since JBAS-1442 it has been possible to change the invocation policies > like local invocation optimizations. > This is handled by subclassing the org.jboss.invocation.InvokerInterceptor > The only one that is direclty supported by simple configuration is whether > marshalling of invocations should take place. > This feature request is to deal with the more common polices > like turning off the local optimization when you want to force load > balancing to an SLSB even though it is availabe locally. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1305) JSR77: ServiceModule should have a parent module to define the scope

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1305?page=all ] Dimitris Andreadis updated JBAS-1305: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) (was: JBossAS-5.0.1.CR1) Assignee: (was: Dimitris Andreadis) > JSR77: ServiceModule should have a parent module to define the scope > -------------------------------------------------------------------- > > Key: JBAS-1305 > URL: http://jira.jboss.com/jira/browse/JBAS-1305 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Management services > Affects Versions: JBossAS-4.0.1 Final > Environment: Java version: 1.5.0,Sun Microsystems Inc. > Java VM: Java HotSpot(TM) Server VM 1.5.0-b64,Sun Microsystems Inc. > OS-System: Linux 2.4.21-4.EL,i386 > Reporter: Michael Kopp > Fix For: JBossAS-4.2.1.CR1 > > > If one has two -service.xml files with the same filename in different locations in the ear, there will only ever be one respective ServiceModule in the J2EE Management. > The reason for this is that there is no scope defined in the name, hence the filename has to be server-wide unique. > A ServiceModule should have a parent module like the EjbModule, which should make it possible to: > - have the same file name multiple times > - on the Server > - in one Application > - link the ServiceModule to the Application it belongs to. > Forum Topic: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3862704#3862704 -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (EJBTHREE-619) Build EJB Timer Service on top of Quartz

by Carlo de Wolf (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-619?page=comments#action_12348926 ] Carlo de Wolf commented on EJBTHREE-619: ---------------------------------------- This is a prototype implementation and will probably not be supported in the future. > Build EJB Timer Service on top of Quartz > ---------------------------------------- > > Key: EJBTHREE-619 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-619 > Project: EJB 3.0 > Issue Type: Feature Request > Reporter: Carlo de Wolf > Assigned To: Carlo de Wolf > Fix For: EJB 3.0 RC9 - FD > > -- 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, 7 months

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