May 2012 - jboss-remoting-issues - Jboss List Archives

[JBoss JIRA] Created: (JBREM-988) Watch org.jboss.test.remoting.stream.StreamingTestCase for failures

by Ron Sigal (JIRA)

Watch org.jboss.test.remoting.stream.StreamingTestCase for failures ------------------------------------------------------------------- Key: JBREM-988 URL: http://jira.jboss.com/jira/browse/JBREM-988 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.1.Beta org.jboss.test.remoting.stream.StreamingTestCase has failed a few times in hudson. Should watch for more failures. -- 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

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1163) Evaluate FindBugs reports

by Ron Sigal (JIRA)

Evaluate FindBugs reports ------------------------- Key: JBREM-1163 URL: https://jira.jboss.org/jira/browse/JBREM-1163 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP1 (Flounder) http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-findbug... and http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-5.x-findbugs/... -- 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

12 years, 5 months

1
11
0 / 0

[JBoss JIRA] (JBREM-1305) Maximum number of client sockets in MicroSocketClientInvoker increases after timeout waiting for a free socket

by Torsten Neise (JIRA)

Torsten Neise created JBREM-1305: ------------------------------------ Summary: Maximum number of client sockets in MicroSocketClientInvoker increases after timeout waiting for a free socket Key: JBREM-1305 URL: https://issues.jboss.org/browse/JBREM-1305 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.5.4.SP3, 2.2.4, 2.5.2.SP3 (Flounder), 2.5.0.SP2 (Flounder) , 2.4.0.SP1 (Pinto) Environment: all Reporter: Torsten Neise Maximum number of client sockets in MicroSocketClientInvoker increases after timeout waiting for a free socket. This happens because of an illegal call of semaphore.release() in MicroSocketClientInvoker.transport(...) after semaphore.attempt(timeToWait) returned with false (no lock aquired) in MicroSocketClientInvoker.getConnection(...). public class MicroSocketClientInvoker extends RemoteClientInvoker { ... protected Object transport(String sessionID, Object invocation, Map metadata, Marshaller marshaller, UnMarshaller unmarshaller) throws IOException, ConnectionFailedException, ClassNotFoundException { ... try { socketWrapper = getConnection(marshaller, unmarshaller, timeLeft); } ... catch (Exception e) { // if (bailOut) // return null; semaphore.release(); ... } ... } protected SocketWrapper getConnection(Marshaller marshaller, UnMarshaller unmarshaller, int timeAllowed) throws Exception { long start = System.currentTimeMillis(); long timeToWait = (timeAllowed > 0) ? timeAllowed : 30000; boolean timedout = !semaphore.attempt(timeToWait); if (trace) log.trace(this + " obtained semaphore: " + semaphore.permits()); if (timedout) { throw new IllegalStateException("Timeout waiting for a free socket"); } ... } ... } -- 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

12 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-1301) WebUtil.isBinary fails when charSet appended

by Tom Cunningham (JIRA)

WebUtil.isBinary fails when charSet appended -------------------------------------------- Key: JBREM-1301 URL: https://issues.jboss.org/browse/JBREM-1301 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: jmx remoting, marshall Affects Versions: 2.5.4.SP2 Reporter: Tom Cunningham WebUtil.isBinary fails when the contentType equals application/octet-stream?charSet=UTF-8 It only accepts "application/octet-stream" as valid. On 1.6.0_21, I'm receiving "application/octet-stream?charSet=UTF-8" as my ContentType from HttpUrlConnection.getHeaderFields() within HttpClientInvoker, which overwrites any ContentType I try to send in a map. Because of this, my responses are InvocationResponses, but they are treated as a string and not unmarshalled. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

4
5
0 / 0

[JBoss JIRA] (JBREM-1302) Can't invoke remote object if server bind address is 0.0.0.0

by Sergey Chernov (Created) (JIRA)

Can't invoke remote object if server bind address is 0.0.0.0 ------------------------------------------------------------ Key: JBREM-1302 URL: https://issues.jboss.org/browse/JBREM-1302 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.5.4.SP2 Environment: Jboss 5.1.0 jdk 1.6 jboss remoting 2.5.4.SP2 Reporter: Sergey Chernov When jboss bind address is set to `0.0.0.0` remote client gets exception while trying to invoke remote object's method: java.rmi.ConnectException: Connection refused to host: lx4-schernov.nn.five9.com; nested exception is: java.net.ConnectException: Connection refused: connect at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601) at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198) at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110) at org.jboss.remoting.transport.rmi.RMIServerInvoker_Stub.transport(Unknown Source) at org.jboss.remoting.transport.rmi.RMIClientInvoker.callTransport(RMIClientInvoker.java:648) at org.jboss.remoting.transport.rmi.RMIClientInvoker.access$100(RMIClientInvoker.java:78) at org.jboss.remoting.transport.rmi.RMIClientInvoker$1.run(RMIClientInvoker.java:402) at org.jboss.util.threadpool.RunnableTaskWrapper.run(RunnableTaskWrapper.java:147) at org.jboss.util.threadpool.BasicThreadPool.executeOnThread(BasicThreadPool.java:473) at org.jboss.util.threadpool.BasicThreadPool.runTaskWrapper(BasicThreadPool.java:201) at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:420) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:169) at org.jboss.remoting.Client.invoke(Client.java:2070) at org.jboss.remoting.Client.invoke(Client.java:879) at org.jboss.remoting.Client.invoke(Client.java:867) at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:479) at $Proxy0.getMySumHost(Unknown Source) at test.Main.main(Main.java:45) Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:193) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:525) at java.net.Socket.connect(Socket.java:475) at java.net.Socket.<init>(Socket.java:372) at java.net.Socket.<init>(Socket.java:186) at javax.net.DefaultSocketFactory.createSocket(SocketFactory.java:206) at org.jboss.remoting.transport.rmi.RemotingRMIClientSocketFactory.createSocketPrivate(RemotingRMIClientSocketFactory.java:333) at org.jboss.remoting.transport.rmi.RemotingRMIClientSocketFactory.createSocket(RemotingRMIClientSocketFactory.java:210) at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595) ... 18 more It happens because RemotingRMIClientSocketFactory had been created with wrong ('0.0.0.0') host name which becomes effective host while creating socket: log: 328 [main] TRACE org.jboss.remoting.transport.rmi.RemotingRMIClientSocketFactory - host: lx4-schernov.nn.five9.com, effective host: 0.0.0.0, port: 47952 source: public Socket createSocket(String host, final int port) throws IOException 176 { ... 181 final String effectiveHost = hostName != null ? hostName : host; While creating factory it should be checked, that host name is not broadcast or localhost address, to make client's locatorUri mandatory for such cases. Client source code: String address = "remote.host.com"; Properties props = new Properties(); props.put(InitialContext.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); props.put(InitialContext.PROVIDER_URL, "jnp://" + address + ":1099"); props.put(InitialContext.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces"); InitialContext context = new InitialContext(props); Object tmp = context.lookup("remote/subsystem/Object"); ObjectInf object = (ObjectInf) tmp; object.doJob(); // here exception it thrown -- 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

12 years, 5 months

5
5
0 / 0

[JBoss JIRA] (JBREM-1306) Remoting tries to create SSLSocketFactory even when not desired

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1306?page=com.atlassian.jira.plugin... ] Ron Sigal reassigned JBREM-1306: -------------------------------- Assignee: Ron Sigal (was: Kyle Lape) > Remoting tries to create SSLSocketFactory even when not desired > --------------------------------------------------------------- > > Key: JBREM-1306 > URL: https://issues.jboss.org/browse/JBREM-1306 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.4, 2.5.4.SP3 > Reporter: Kyle Lape > Assignee: Ron Sigal > Priority: Minor > Fix For: 2.2.4.SP1, 2.5.4.SP4 > > > Running the following code is an alternative way to set the keystore/truststore in a remoting client: > {noformat} > KeyStore ksTrust = KeyStore.getInstance("JKS"); > ksTrust.load(new FileInputStream("testTrust"), passphrase); > TrustManagerFactory tmf = > TrustManagerFactory.getInstance("SunX509"); > tmf.init(ksTrust); > SSLContext sslContext = SSLContext.getInstance("TLS"); > sslContext.init(null, tmf.getTrustManagers(), null); > HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory()); > {noformat} > When this code is added, Remoting should not try to create its own {{SSLSocketFactory}}. Currently there is no way to tell Remoting to not try. This causes a confusing ERROR message: > {noformat} > Error creating SSL Socket Factory for client invoker: Error initializing socket factory SSL context: Can not find truststore url. > {noformat} > After this message is logged, the client still works because it falls back to the default {{SSLSocketFactory}} (that was already set). -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1306) Remoting tries to create SSLSocketFactory even when not desired

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1306?page=com.atlassian.jira.plugin... ] Ron Sigal moved JBPAPP-9187 to JBREM-1306: ------------------------------------------ Project: JBoss Remoting (was: JBoss Enterprise Application Platform) Key: JBREM-1306 (was: JBPAPP-9187) Affects Version/s: 2.5.4.SP3 2.2.4 (was: EAP_EWP 5.1.2) Component/s: (was: Remoting) (was: Web Services) Fix Version/s: 2.2.4.SP1 2.5.4.SP4 (was: EAP_EWP 5.1.3) Docs QE Status: (was: NEW) > Remoting tries to create SSLSocketFactory even when not desired > --------------------------------------------------------------- > > Key: JBREM-1306 > URL: https://issues.jboss.org/browse/JBREM-1306 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.5.4.SP3, 2.2.4 > Reporter: Kyle Lape > Assignee: Kyle Lape > Priority: Minor > Fix For: 2.2.4.SP1, 2.5.4.SP4 > > > Running the following code is an alternative way to set the keystore/truststore in a remoting client: > {noformat} > KeyStore ksTrust = KeyStore.getInstance("JKS"); > ksTrust.load(new FileInputStream("testTrust"), passphrase); > TrustManagerFactory tmf = > TrustManagerFactory.getInstance("SunX509"); > tmf.init(ksTrust); > SSLContext sslContext = SSLContext.getInstance("TLS"); > sslContext.init(null, tmf.getTrustManagers(), null); > HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory()); > {noformat} > When this code is added, Remoting should not try to create its own {{SSLSocketFactory}}. Currently there is no way to tell Remoting to not try. This causes a confusing ERROR message: > {noformat} > Error creating SSL Socket Factory for client invoker: Error initializing socket factory SSL context: Can not find truststore url. > {noformat} > After this message is logged, the client still works because it falls back to the default {{SSLSocketFactory}} (that was already set). -- 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

12 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues May 2012