July 2007 - jboss-jira - Jboss List Archives

[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

17 years, 6 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

17 years, 6 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

17 years, 6 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

17 years, 6 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

17 years, 6 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

17 years, 6 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

17 years, 6 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

17 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-951) Strange NullPointerException in rule compilation with Iterator in RHS

by Alexandre Gattiker (JIRA)

Strange NullPointerException in rule compilation with Iterator in RHS --------------------------------------------------------------------- Key: JBRULES-951 URL: http://jira.jboss.com/jira/browse/JBRULES-951 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.MR3 Environment: IBM RAD 7 Reporter: Alexandre Gattiker Assigned To: Mark Proctor Create a new Rules Project In Sample.drl add "import java.util.*;" at the top, and within the consequence block of one of the two rules: ArrayList list = new ArrayList(); for (Iterator iter = list.iterator(); iter.hasNext();) { } Eclipse reports a problem: Severity and Description Path Resource Location Creation Time Id Error: java.lang.NullPointerException droolstest6/src/rules Sample.drl Unknown 1182938042901 228615 When executing DroolsTest I get: java.lang.NullPointerException at org.drools.rule.builder.dialect.java.JavaConsequenceBuilder.build(JavaConsequenceBuilder.java:54) at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:67) at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:390) at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:264) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:147) at com.sample.DroolsTest.readRule(DroolsTest.java:54) at com.sample.DroolsTest.main(DroolsTest.java:21) With 4.0.0.MR2 the bug does not happen. -- 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

17 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (BPEL-228) move endpoint references to a separate package

by Alejandro Guizar (JIRA)

move endpoint references to a separate package ---------------------------------------------- Key: BPEL-228 URL: http://jira.jboss.com/jira/browse/BPEL-228 Project: JBoss jBPM BPEL Issue Type: Task Security Level: Public (Everyone can see) Components: Engine Reporter: Alejandro Guizar Assigned To: Alejandro Guizar Fix For: jBPM BPEL 1.1 beta 3 In BPEL 2, endpoint references have been turned into an extensible mechanism, just like sublanguages. Moving endpoint references to a separate package is meant as an aid for the end developer to understand the structure and the components of the mechanism. -- 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

17 years, 6 months

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