February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-681) Multi-threaded local search solving

by Geoffrey De Smet (JIRA)

Multi-threaded local search solving ----------------------------------- Key: JBRULES-681 URL: http://jira.jboss.com/jira/browse/JBRULES-681 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Optional Use Future's to spread all possible moves in each step over a number of threads. This number of threads is equal to the number of cpu's by default, as no IO is done during solving. Problems: - each thread will needs it own WorkingMemory and during a step, each working memory will need to be updated - a bunch of classes will need to be thread safe, or at least visibility save, such as bestsolutionrecaller. - Barriers will be needed to collect the result of each step - decks might be a great way to spread out the load -- 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

12 years, 9 months

1
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-880) Hard-coded localhost in ejb3 test suite

by Aleksandar Kostadinov (JIRA)

Hard-coded localhost in ejb3 test suite --------------------------------------- Key: EJBTHREE-880 URL: http://jira.jboss.com/jira/browse/EJBTHREE-880 Project: EJB 3.0 Issue Type: Bug Reporter: Aleksandar Kostadinov When the ejb3 testsuite is run with "-Dnode0=IP1 -Dnode1=IP2" and IP1!=localhost there are some tests failing with "Retries exceeded, couldn't reconnect to 127.0.0.1:####". I see this for 4_0 and 4_2 jboss branches, but guess it's the same with head. One of the testcases is IiopRemoteUnitTestCase. I've checked ejb3/src/test/org/jboss/ejb3/test/iiop/unit/IiopRemoteUnitTestCase.java and there is 'props.put("java.naming.provider.url", "corbaloc::localhost:3528/NameService");'. Instead of localhost there should be used the node0 property. I guess the others have the same problem. -- 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

12 years, 9 months

6
16
0 / 0

[JBoss JIRA] Created: (JBRULES-443) Release drools binaries with debug information

by Juergen none (JIRA)

Release drools binaries with debug information ---------------------------------------------- Key: JBRULES-443 URL: http://jira.jboss.com/jira/browse/JBRULES-443 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Juergen none Assigned To: Mark Proctor Priority: Trivial Would it be possible to supply a debug-build of the binaries in addition to the existing downloads (where at least the drools jar files are without debug-info)? -- 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

13 years

3
4
0 / 0

[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException

by John Mazzitelli (JIRA)

cannot init cause of ClassCastException --------------------------------------- Key: JBREM-552 URL: http://jira.jboss.com/jira/browse/JBREM-552 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.Beta2 (Boon) Reporter: John Mazzitelli Assigned To: Tom Elrod Priority: Minor Fix For: 2.0.0.CR1 (Boon) I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown: java.lang.IllegalStateException: Can't overwrite cause at java.lang.Throwable.initCause(Throwable.java:320) at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447) at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324) at org.jboss.remoting.Client.connect(Client.java:385) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430) at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167) at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820) at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102) Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written). The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor. e.g.: new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e); (notice the ", e" parameter). There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here. -- 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

13 years

5
5
0 / 0

[JBoss JIRA] Created: (JBREM-646) dynamic loading of new keystores during runtime is not possible when using Transporters (beaming POJOs)

by Claudia Richter (JIRA)

dynamic loading of new keystores during runtime is not possible when using Transporters (beaming POJOs) ------------------------------------------------------------------------------------------------------- Key: JBREM-646 URL: http://jira.jboss.com/jira/browse/JBREM-646 Project: JBoss Remoting Issue Type: Patch Security Level: Public (Everyone can see) Components: transporter Environment: ?? Reporter: Claudia Richter Assigned To: Tom Elrod when running a Transporter Server and a Transporter Client, using SSL connection, the Transporter Server does not recognise changes within its Truststore, if this is updated. Means, if the Client is not trusted when starting the Server, it will not be trusted for future request until the Server is restarted. It would be better to have a Server that is able to recognise Truststore changes. This feature is already implemented for other transports (no Transporters) as described in issue http://jira.jboss.com/jira/browse/JBREM-427. -- 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

13 years, 1 month

4
7
0 / 0

[JBoss JIRA] Created: (JBREM-652) allow passing of config map when creating transporter client

by Tom Elrod (JIRA)

allow passing of config map when creating transporter client ------------------------------------------------------------ Key: JBREM-652 URL: http://jira.jboss.com/jira/browse/JBREM-652 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.0.Alpha4 Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Currently the transporter client can only be created using invoker locator for configuration. Need to add to the api so can pass config map which gets passed to the remoting client that is created so can customize things such as ssl config. For example, would be need to be able to something like is done in org.jboss.test.remoting.transport.socket.ssl.custom.InvokerClientTest with a transporter client. -- 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

13 years, 1 month

3
4
0 / 0

[JBoss JIRA] Created: (JBREM-591) Make asynchronous calls using Transporter

by vivek v (JIRA)

Make asynchronous calls using Transporter ----------------------------------------- Key: JBREM-591 URL: http://jira.jboss.com/jira/browse/JBREM-591 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: transporter Reporter: vivek v Assigned To: Tom Elrod This came out of the user forum question, http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89224 Currently, there is a mechanism to do asynchronous calls and callbacks using InvocationHandler. As more and more people are using POJOs (via Transporter) for remoting it would be great if we can have the same features (both asynchronous calls and callbacks) available for the Transporter. Couple of use cases can be, Asynchronous Call ----------------------------- 1) Client makes a simple method call (using POJO) on server 2) Server gets the request and returns immediately to the Client. Now Client is free to do its own stuff without waiting or polling for the result. 3) Server starts processing the request 4) When the response is ready Server sends the response to the Client. Callbacks -------------------- 1) An alert happens on the server side 2) Server should be able to send the alert to the Client without Client requesting for 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

13 years, 1 month

4
5
0 / 0

[JBoss JIRA] Created: (JBREM-585) there is the need to add a callback listener for ssl stream invocation

by Michael Voss (JIRA)

there is the need to add a callback listener for ssl stream invocation ---------------------------------------------------------------------- Key: JBREM-585 URL: http://jira.jboss.com/jira/browse/JBREM-585 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: stream Affects Versions: 2.0.0.CR1 (Boon) Reporter: Michael Voss Assigned To: Tom Elrod Fix For: 2.0.0.GA (Boon) If want to use existing ssl connector for stream invocation (using Client.invoke(InputStream,Object,Connector) ) the client has to add a callback listener to run the the invocation properly I think stream invocation should also work without the need to add a callback listener if no listener is added the following exception is thrown: by stream sender: org.jboss.remoting.ConnectionFailedException: Connection has been shutdown: javax.net.ssl.SSLProtocolException: Illegal client handshake msg, 1 at org.jboss.remoting.transport.multiplex.MultiplexClientInvoker.handleConnect(MultiplexClientInvoker.java:111) at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:252) at org.jboss.remoting.Client.connect(Client.java:391) at org.jboss.remoting.Client.connect(Client.java:383) at org.jboss.remoting.stream.StreamHandler.<init>(StreamHandler.java:77) at org.jboss.remoting.ServerInvoker.getStreamHandler(ServerInvoker.java:1253) at org.jboss.remoting.ServerInvoker.handleInternalInvocation(ServerInvoker.java:1225) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:983) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:848) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:447) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:520) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:257) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163) at org.jboss.remoting.Client.invoke(Client.java:612) at org.jboss.remoting.Client.invoke(Client.java:604) at org.jboss.remoting.Client.invoke(Client.java:1211) by stream receiver: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLProto colException: Illegal client handshake msg, 1 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(Unknown Source) at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at org.jboss.remoting.transport.multiplex.InputMultiplexor$SingleGroupIn putThread.completeHeader(InputMultiplexor.java:608) at org.jboss.remoting.transport.multiplex.InputMultiplexor$SingleGroupIn putThread.doRun(InputMultiplexor.java:540) at org.jboss.remoting.transport.multiplex.utility.StoppableThread.run(St oppableThread.java:54) Caused by: javax.net.ssl.SSLProtocolException: Illegal client handshake msg, 1 at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source ) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Un known Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source ) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source) at java.io.OutputStream.write(Unknown Source) at org.jboss.remoting.transport.multiplex.OutputMultiplexor$OutputThread .encode(OutputMultiplexor.java:580) at org.jboss.remoting.transport.multiplex.OutputMultiplexor$OutputThread .doRun(OutputMultiplexor.java:452) ... 1 more -- 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

13 years, 1 month

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-552) Outline problems in DRL editor

by Dirk Bergstrom (JIRA)

Outline problems in DRL editor ------------------------------ Key: JBRULES-552 URL: http://jira.jboss.com/jira/browse/JBRULES-552 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.4 Reporter: Dirk Bergstrom Assigned To: Mark Proctor Priority: Minor Two (possibly related) problems with the outline view in the DRL editor: *) Rules that are commented out via a multi-line comment (/* ... */) still appear in the outline. *) Clicking on the name of a rule highlights some text near that rule. I assume it's supposed to highight the title of the rule, but it misses. Same thing affects the imports. -- 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

13 years, 3 months

4
5
0 / 0

[JBoss JIRA] Created: (JBFORUMS-122) Links should be recognized

by Thomas Diesler (JIRA)

Links should be recognized -------------------------- Key: JBFORUMS-122 URL: http://jira.jboss.com/jira/browse/JBFORUMS-122 Project: JBoss Forums Issue Type: Feature Request Components: Forum Enhancements Reporter: Thomas Diesler Assigned To: Sohil Shah Instead of [url]http://jira.jboss.com/jira/secure/CreateIssue.jspa[/url] I like to simply use http://jira.jboss.com/jira/secure/CreateIssue.jspa There are a lot of user provided links that I cannot click on. -- 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

13 years, 5 months

4
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2007