[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
12 years, 5 months
[JBoss JIRA] Created: (JBRULES-1075) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
-----------------------------------------------------------------------------------------------------
Key: JBRULES-1075
URL: http://jira.jboss.com/jira/browse/JBRULES-1075
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 4.0.0.GA
Reporter: Geoffrey De Smet
Assigned To: Edson Tirelli
Priority: Minor
Fix For: FUTURE
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
--
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, 5 months
[JBoss JIRA] Created: (JGRP-693) Incorporate MultithreadedTestCase (MTC) usage into JGroups testsuite
by Richard Achmatowicz (JIRA)
Incorporate MultithreadedTestCase (MTC) usage into JGroups testsuite
--------------------------------------------------------------------
Key: JGRP-693
URL: http://jira.jboss.com/jira/browse/JGRP-693
Project: JGroups
Issue Type: Task
Environment: JGroups testsuite test cases
Reporter: Richard Achmatowicz
Assigned To: Bela Ban
Fix For: 2.7
MultithreadedTestCase (MTC) is an open-source testing framework which supports the writing of multithreaded test cases. It introduces a global tick-counter which provides a deterministic form of thread synchronization, based on the number of times all threads in a test case are blocked. The tool works well ina debugger, unlike other approximate forms of synchronization (e.g. sleep())
This issue concerns using MTC in order to simplify and improve test cases in the JGroups test suite in which concurrency and blocking are at issue.
--
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, 7 months