July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JGRP-170) upTbl should be cleared in _upViewChange()

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-170?page=all ] Bela Ban closed JGRP-170. ------------------------- Resolution: Out of Date TOTAL was canned in 2.5 > upTbl should be cleared in _upViewChange() > ------------------------------------------ > > Key: JGRP-170 > URL: http://jira.jboss.com/jira/browse/JGRP-170 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.2.9, 2.2.9.1, 2.2.8 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.x > > > upTbl should be cleared in _upViewChange(). > Say there are three nodes A,B,C. Suppose there are 10 > outstanding TOTAL sequences say 1-10 (1-5 from A and > 6-10 from B). Say seq#1 is missing so we have 2-10 in > every upTbl. > Now assume the view changes and A and B replayBcast > (). This time A gets 6-10 and B gets 1-5. > A lot can go wrong now, say if A's sequences reach in > reverse order. We have duplicate transmissions from A. > Its also possible that B's transmission is totally lost. > I haven't verified all possible scenarios here, but I think > the above two are quite possible. -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-443) Verify JGroups runs on JDK 6

by Bela Ban (JIRA)

Verify JGroups runs on JDK 6 ---------------------------- Key: JGRP-443 URL: http://jira.jboss.com/jira/browse/JGRP-443 Project: JGroups Issue Type: Task Affects Versions: 2.5 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.x -- 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

18 years, 5 months

2
3
0 / 0

[JBoss JIRA] Resolved: (JGRP-201) Benchmarks on GB switch with jumbo ethernet frames

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-201?page=all ] Bela Ban resolved JGRP-201. --------------------------- Resolution: Done done, tests are at http://www.jgroups.org/javagroupsnew/perfnew/Report.html > Benchmarks on GB switch with jumbo ethernet frames > -------------------------------------------------- > > Key: JGRP-201 > URL: http://jira.jboss.com/jira/browse/JGRP-201 > Project: JGroups > Issue Type: Task > Affects Versions: 2.2.8, 2.2.9, 2.3, 2.4, 2.2.9.1 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.5 > > > Run the perf.Test benchmark with jumbo frames -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JGRP-201) Benchmarks on GB switch with jumbo ethernet frames

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-201?page=all ] Bela Ban updated JGRP-201: -------------------------- Fix Version/s: 2.5 (was: 2.x) > Benchmarks on GB switch with jumbo ethernet frames > -------------------------------------------------- > > Key: JGRP-201 > URL: http://jira.jboss.com/jira/browse/JGRP-201 > Project: JGroups > Issue Type: Task > Affects Versions: 2.2.8, 2.2.9, 2.3, 2.4, 2.2.9.1 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.5 > > > Run the perf.Test benchmark with jumbo frames -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-414) Backport of 2.5 to run on JDK 1.4

by Bela Ban (JIRA)

Backport of 2.5 to run on JDK 1.4 --------------------------------- Key: JGRP-414 URL: http://jira.jboss.com/jira/browse/JGRP-414 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Investigate whether 2.5 can be backported (retro and JSR 166 backport) to run on JDK 1.4 -- 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

18 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-533) RpcDispatcher: thread pool to provide interruptible cluster call invocations

by Bela Ban (JIRA)

RpcDispatcher: thread pool to provide interruptible cluster call invocations ---------------------------------------------------------------------------- Key: JGRP-533 URL: http://jira.jboss.com/jira/browse/JGRP-533 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4.1 SP4, 2.5 This is to solve http://jira.jboss.com/jira/browse/JBCACHE-1103, especially in 2.4. (In 2.5, we have OOB messages that deliver credit responses). SOLUTION: Th idea is to have 1 additional callRemoteMethod(s) method, which takes a timeout > 0 and a boolean use_thread_pool. If the boolean is false, then we have the default behavior: send the request, then block until all responses have been received. Else, the behavor is the following: - Create a task that is scheduled with a thread pool and as result get a Future. (The thread pool might get created per RpcDispatcher or as static member of the RpcDispatcher class, and it is configured via system props). - Block on the Future for timeout milliseconds - If all the responses have been received: - Set the result in the Future and notify it, so the caller unblocks and returns - If the timeout elapsed: - Interrupt the task (e.g. thread blocked in FC.down() will return, and mark the GroupRequest as 'done' so further responses are ignored) and return the current results with the RpcList, unblocking the caller The decision whether or not to use a thread pool is *per method call*, so we don't have the overhead of the thread pool for regular calls. This is only necessary for 2.4, as we only have a single request queue, which caused JBCACHE-1103. In 2.5, this will not happen. Question is do we want to forward-port this to 2.5 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

18 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-542) MPING: add bind_interfaces to define list of interfaces to listen for discovery requests

by Bela Ban (JIRA)

MPING: add bind_interfaces to define list of interfaces to listen for discovery requests ---------------------------------------------------------------------------------------- Key: JGRP-542 URL: http://jira.jboss.com/jira/browse/JGRP-542 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4.1 SP4, 2.5 Same as in TP -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-962) declaring dialect at package level doesn't work (it just breaks lots of stuff siltently)

by Michael Neale (JIRA)

declaring dialect at package level doesn't work (it just breaks lots of stuff siltently) ---------------------------------------------------------------------------------------- Key: JBRULES-962 URL: http://jira.jboss.com/jira/browse/JBRULES-962 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.MR3 Reporter: Michael Neale Assigned To: Mark Proctor Priority: Critical To reproduce, simply try putting dialect "mvel" at the package level, and nothing in the individual rules (dialect attribute wise) and it just won't work. -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-974) Unable to process control connection

by Tim Fox (JIRA)

Unable to process control connection ------------------------------------ Key: JBMESSAGING-974 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-974 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Ron Sigal Fix For: 1.3.0.GA When running messaging remote tests (ant remote-tests from tests dir). At various points, JBoss Remoting is logging the following: [junit] @control: Socket[addr=/127.0.0.1,port=2960,localport=58358] 17:09:54,929 ERROR [BisocketServerInvoker] Unable to process control connection: Socket closed [junit] java.net.SocketException: Socket closed [junit] at java.net.SocketInputStream.socketRead0(Native Method) [junit] at java.net.SocketInputStream.read(SocketInputStream.java:129) [junit] at java.net.SocketInputStream.read(SocketInputStream.java:182) [junit] at java.io.FilterInputStream.read(FilterInputStream.java:66) [junit] at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:652) This doesn't seem to cause the tests to fail, and is annoying. I guess remoting is trying to clear up its state and failing (??) -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-963) Allows Stateless Sessions to be re-usable

by Mark Proctor (JIRA)

Allows Stateless Sessions to be re-usable ----------------------------------------- Key: JBRULES-963 URL: http://jira.jboss.com/jira/browse/JBRULES-963 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rule Assemply/SPI Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 4.0.0.MR4 Stateless Sessions are not currently re-usable. To make them useable you will have to allow those sessions to inject the globals and event support objects. -- 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

18 years, 5 months

1
1
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 2007