September 2009 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1146) Treat IOException("Connection reset by peer") as a retriable exception

by Ron Sigal (JIRA)

Treat IOException("Connection reset by peer") as a retriable exception ---------------------------------------------------------------------- Key: JBREM-1146 URL: https://jira.jboss.org/jira/browse/JBREM-1146 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.3, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder), 2.2.3.SP1 org.jboss.remoting.transport.socket.MicroSocketClientInvoker uses the parameter "numberOfCallRetries" to determine the number of invocation attempts to make upon receiving java.net.SocketExceptions. For example, SocketException("Connection reset") will cause MicroSocketClientInvoker to get another socket and try again. However, if a connection is reset on the other side, then an IOException("Connection reset by peer") is thrown, which doesn't lead to a retry. It should be possible to configure the socket transport to treat an IOException("Connection reset by peer") as retriable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
4
0 / 0

[JBoss JIRA] Updated: (JBREM-318) add remoting based chat sample

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-318?page=com.atlassian.jira.plug... ] Ron Sigal updated JBREM-318: ---------------------------- Assignee: Ron Sigal (was: Ron Sigal) > add remoting based chat sample > ------------------------------ > > Key: JBREM-318 > URL: https://jira.jboss.org/jira/browse/JBREM-318 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > Assignee: Ron Sigal > Priority: Optional > Fix For: 2.5.3.Beta (Flounder) > > > Add a simple chat application using remoting for the communication layer to the remoting samples. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-833) HTTP Transport Implementation

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-833?page=com.atlassian.jira.plug... ] Ron Sigal updated JBREM-833: ---------------------------- Assignee: Ron Sigal (was: Ron Sigal) > HTTP Transport Implementation > ----------------------------- > > Key: JBREM-833 > URL: https://jira.jboss.org/jira/browse/JBREM-833 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Assignee: Ron Sigal > Fix For: 3.1.0.Beta1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

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

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-324?page=com.atlassian.jira.plug... ] Ron Sigal updated JBREM-324: ---------------------------- Assignee: Ron Sigal (was: Ron Sigal) > Facility for real-time decision on best InvokerLocator by which to contact a given handler. > ------------------------------------------------------------------------------------------- > > Key: JBREM-324 > URL: https://jira.jboss.org/jira/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 contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

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

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-646?page=com.atlassian.jira.plug... ] Ron Sigal updated JBREM-646: ---------------------------- Assignee: Ron Sigal (was: Ron Sigal) > dynamic loading of new keystores during runtime is not possible when using Transporters (beaming POJOs) > ------------------------------------------------------------------------------------------------------- > > Key: JBREM-646 > URL: https://jira.jboss.org/jira/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 contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

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

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-424?page=com.atlassian.jira.plug... ] Ron Sigal updated JBREM-424: ---------------------------- Assignee: Ron Sigal (was: Ron Sigal) > Convert HA-JNDI stubs to Remoting > --------------------------------- > > Key: JBREM-424 > URL: https://jira.jboss.org/jira/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 contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1150) Lease should update client list if PING invocation has same time as previous PING

by Ron Sigal (JIRA)

Lease should update client list if PING invocation has same time as previous PING --------------------------------------------------------------------------------- Key: JBREM-1150 URL: https://jira.jboss.org/jira/browse/JBREM-1150 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder), 2.2.3.SP1 When an org.jboss.remoting.lease is created, in response to org.jboss.remoting.MicroRemotingClientInvoker sending a PING, it has no clients. The next PING invocation, generated by org.jboss.remoting.LeasePinger.addClient(), supplies a list of clients. However, Lease updates its client list only if the timestamp in the InvocationRequest is greater than the timestamp of the previous InvocationRequest. Since the two PINGs that create a Lease could have the same timestamp, the test in Lease should be >= instead of >. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1105) DefaultLoadBalancer doesn't use all available server (if there are x servers available it uses x-1 of these)

by Mikael Thorman (JIRA)

DefaultLoadBalancer doesn't use all available server (if there are x servers available it uses x-1 of these) ------------------------------------------------------------------------------------------------------------ Key: JBREM-1105 URL: https://jira.jboss.org/jira/browse/JBREM-1105 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.2.SP10 Environment: JBoss EAP 4.3.0, Windows XP, Java 1.6.0_11 Reporter: Mikael Thorman Invalid use of the Random nextInt function in class: org.jboss.remoting.transporter.DefaultLoadBalancer function: selectServer Current code: index = new Random().nextInt(size - 1); Should be: index = new Random().nextInt(size); tested current code with 2 servers and it always chooses the first one until this is shut, first after this it uses the second one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-1143) CLONE [JBREM-877] - New Socket Connection is being Created for Every Client Request to the Server

by Ron Sigal (JIRA)

CLONE [JBREM-877] - New Socket Connection is being Created for Every Client Request to the Server ------------------------------------------------------------------------------------------------- Key: JBREM-1143 URL: https://jira.jboss.org/jira/browse/JBREM-1143 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.2.SP2 Environment: Linux os , Pentium duo Processor with 3.6 Ghz clock Speed, 4GB Ram in this Postgresql Database also Running Reporter: Kumarselvan Somasundaram Assignee: Ron Sigal Priority: Critical Fix For: 2.4.0.Beta2 (Pinto) whenever EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization, The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0 new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues September 2009