November 2011 - jboss-remoting-issues

[JBoss JIRA] (JBREM-738) ServerThread/invoker still executing invocation after its related TransportServer was stopped

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-738?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-738. --------------------------- Resolution: Won't Fix > ServerThread/invoker still executing invocation after its related TransportServer was stopped > --------------------------------------------------------------------------------------------- > > Key: JBREM-738 > URL: https://issues.jboss.org/browse/JBREM-738 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transporter > Affects Versions: 2.4.0.Beta1 (Pinto) > Environment: java 1.5 on solaris but doubt its specific to this one. > Reporter: craig bordelon > Fix For: 2.5.3.Beta (Flounder) > > > get an exception on the third iteration of a transporter client to a transporter server where the client code is doing the same invoke each time. This should not happen as the first two iterations give correct result. The exception is thrown from the server side as apparently the jboss remoting internals are confused -- stating that a ServerInvoker is not in "started state". > Exception is > java.lang.reflect.UndeclaredThrowableException > at $Proxy4.toString(Unknown Source) > at java.lang.String.valueOf(String.java:2615) > at java.lang.StringBuilder.append(StringBuilder.java:116) > at proxy.Client.testClientCall(Client.java:38) > at proxy.Client.main(Client.java:115) > Caused by: org.jboss.remoting.ServerInvoker$InvalidStateException: Can not proc > ess invocation request since is not in started state. > at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:751) > at org.jboss.remoting.transport.socket.ServerThread.processInvocation(S > erverThread.java:568) > at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread. > java:390) > at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.ja > va:164) > at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClient > Invoker.java:163) > at org.jboss.remoting.Client.invoke(Client.java:1548) > at org.jboss.remoting.Client.invoke(Client.java:534) > at org.jboss.remoting.Client.invoke(Client.java:522) > at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterC > lient.java:297) > to reproduce this (one way at least): > run the transporter sample modified for the Client to execute the the makeClientCall multiple times. > Now > to get past the obvious first issue (socket in use) add new code for > customerProcessor.releaseCustomer(processedCustomer.getCustomerId() > in the Client just before the > TransporterClient.destroyTransporterClient(customerProcessor); > Implement this method in the CustomerProcessorImpl to use the id to locate (eg hash get()) the related ICustomer TransporterClient and destroy it and to the TransporterServer to stop it. > This theoretically frees up the Customer "server" allowing for the next iteration by the Client. > note that the processCustomer() implemenation is modified to store the TransporterClient and TransporterServer that are created here. > ------------ > I dug into the code a bit and what i gathered is that a ServerThread is trying to do processInvocation using a SocketServerInvoker that was already "stopped". I think the ServerThread itself should not be executing as the TransporterServer it should be involved with was already stopped. > I posted to the jboss forum on issues i was having trying to make the transporter sample run from the client multiple times. See issue by "bord" on 4/17/2007 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

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

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-646?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-646. --------------------------- Resolution: Rejected > dynamic loading of new keystores during runtime is not possible when using Transporters (beaming POJOs) > ------------------------------------------------------------------------------------------------------- > > Key: JBREM-646 > URL: https://issues.jboss.org/browse/JBREM-646 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: transporter > Affects Versions: 2.2.0.Alpha4 > Environment: ?? > Reporter: Claudia Richter > Assignee: Ron Sigal > Fix For: 2.5.3.Beta (Flounder) > > Attachments: TruststoreBug.zip > > > 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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

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

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-652?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-652. --------------------------- Resolution: Rejected > allow passing of config map when creating transporter client > ------------------------------------------------------------ > > Key: JBREM-652 > URL: https://issues.jboss.org/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 > Fix For: 2.5.3.Beta (Flounder) > > > 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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

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

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-591?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-591. --------------------------- Resolution: Rejected > Make asynchronous calls using Transporter > ----------------------------------------- > > Key: JBREM-591 > URL: https://issues.jboss.org/browse/JBREM-591 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: transporter > Affects Versions: 2.0.0.CR1 (Boon) > Reporter: vivek v > Fix For: 2.5.3.Beta (Flounder) > > > 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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

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

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-585?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-585. --------------------------- Resolution: Rejected > there is the need to add a callback listener for ssl stream invocation > ---------------------------------------------------------------------- > > Key: JBREM-585 > URL: https://issues.jboss.org/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 > Fix For: 2.5.3.Beta (Flounder) > > > 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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-385) Need to pull the legacy invokers into remoting

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-385?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-385. --------------------------- Resolution: Out of Date > Need to pull the legacy invokers into remoting > ---------------------------------------------- > > Key: JBREM-385 > URL: https://issues.jboss.org/browse/JBREM-385 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Scott Stark > > The org.jboss.invocation.* package has dependencies on remoting, and it should just be moved into the remoting project as the legacy remoting impl. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-424) Convert HA-JNDI stubs to Remoting

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-424?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-424. --------------------------- Resolution: Out of Date > Convert HA-JNDI stubs to Remoting > --------------------------------- > > Key: JBREM-424 > URL: https://issues.jboss.org/browse/JBREM-424 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: general > Reporter: Tom Elrod > Assignee: Ron Sigal > Fix For: External_issues > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-344) support for NTLM authentication

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-344?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-344. --------------------------- Resolution: Rejected > support for NTLM authentication > ------------------------------- > > Key: JBREM-344 > URL: https://issues.jboss.org/browse/JBREM-344 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-324) Facility for real-time decision on best InvokerLocator by which to contact a given handler.

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-324?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-324. --------------------------- Resolution: Rejected > Facility for real-time decision on best InvokerLocator by which to contact a given handler. > ------------------------------------------------------------------------------------------- > > Key: JBREM-324 > URL: https://issues.jboss.org/browse/JBREM-324 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ron Sigal > Assignee: Ron Sigal > Priority: Minor > > The basic idea is to be able to communicate with a single handler by way of different InvokerLocators. For example, if you're working over the internet, compression might be advantageous, but if you're local it might not be. So you could have two Connectors sharing a handler, one using the compression marshaller and one not. > How about a client that > 1. gets the InvokerLocators for all of the Connectors for a certain handler, via a detector, > 2. sends some sample invocations to each and times them, and > 3. displays the results. > It could be used for real time decision making or to collect information for a set of rules. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-154) pluggable server resolver in client

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-154?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-154. --------------------------- Resolution: Won't Fix > pluggable server resolver in client > ----------------------------------- > > Key: JBREM-154 > URL: https://issues.jboss.org/browse/JBREM-154 > Project: JBoss Remoting > Issue Type: Feature Request > Components: general > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Priority: Minor > > Per forum thread http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883462#3883462, need ability for the remoting client to have a pluggable way to resolve a server endpoint. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues November 2011