[JBoss JIRA] Commented: (JBREM-920) Create build.xml target to run test suite with a Security Manager
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-920?page=comments#action_12401855 ]
Ron Sigal commented on JBREM-920:
---------------------------------
This is paying off already. org.jboss.remoting.transport.http.HTTPClientInvoker calls Class.getMethod():
java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.net.www.protocol.https)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1491)
at java.lang.Class.checkMemberAccess(Class.java:1450)
at java.lang.Class.getMethod(Class.java:983)
at org.jboss.remoting.transport.http.HTTPClientInvoker.getSimulatedTimeout(HTTPClientInvoker.java:582)
at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:138)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:157)
at org.jboss.remoting.Client.invoke(Client.java:1685)
at org.jboss.remoting.Client.invoke(Client.java:589)
at org.jboss.remoting.Client.invoke(Client.java:577)
at org.jboss.test.remoting.callback.sslsocketfactory.SSLSocketFactoryTestParent.testSSLServerSocketFactory(SSLSocketFactoryTestParent.java:110)
> Create build.xml target to run test suite with a Security Manager
> -----------------------------------------------------------------
>
> Key: JBREM-920
> URL: http://jira.jboss.com/jira/browse/JBREM-920
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Ron Sigal
> Assigned To: David Lloyd
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> From Anil Saldana:
> Presuming that you have a test suite and either use ANT or Maven, I
> recommend an extra target to run the test suite in a Java Security
> Manager with minimal permissions. So for ANT, you will have an
> additional target. For MAVEN, you can use a profile.
> The idea is that you have a Java Security Policy file in which you
> provide unlimited permission to third party libraries and minimal
> permissions to your own code. This exercise is to detect critical
> sections of code that need special privileges and get into privileged
> blocks. If you have an extra target for the security manager and your
> test runs happen on hudson, you can detect issues with security manager
> as new code gets added.
> Please do not have one test that does System.setSecurityManager but run
> your entire test suite via the security manager
> (-Djava.security.manager -Djava.security.policy=somefile).
> Example: (Take a look by clicking "Configure" on the LHS)
> http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/
> http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s...
> Now if your head is spinning or you do not care about security or do not
> have the time to do it, please tell me. I can engage myself, someone
> from JBoss Security Team or the QA person handling your project to add a
> JIRA issue (and make the build.xml/pom.xml changes for your project).
> Why is this important?
> * Because many customers run JBAS in a security manager and we need to
> detect issues in our own code. Also during a recent integration work
> with JBoss Messaging for the SOA platform, there was one issue with
> remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is
> still reeling). It took some cycles from me also.
> * We need to have tests running in a security manager on an ongoing basis.
> I understand that there are resource issues in various projects. But
> that does not discount the work that we need to do before we ship JBAS. ;)
--
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
16 years, 3 months
[JBoss JIRA] Closed: (JBREM-924) Compilation errors in non ISO-8859-1 systems
by David Lloyd (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-924?page=all ]
David Lloyd closed JBREM-924.
-----------------------------
Resolution: Done
I'll mark this as closed - if there's a problem then go ahead and re-open it.
> Compilation errors in non ISO-8859-1 systems
> --------------------------------------------
>
> Key: JBREM-924
> URL: http://jira.jboss.com/jira/browse/JBREM-924
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.4.0.Beta1 (Pinto)
> Environment: Fedora 8, LANG=ko_KR.UTF-8
> Reporter: Trustin Lee
> Assigned To: David Lloyd
> Priority: Trivial
> Fix For: 2.4.0.CR1 (Pinto)
>
> Attachments: remoting2-encoding.diff
>
>
> The default encoding of my machine is UTF-8, but it seems like Remoting 2 trunk source code is encoded in ISO-8859-1. When I run 'ant tests', it bails out with a compilation error that there's a unmappable character in the source code. The solution of this problem is to specify the encoding of the source code explicitly in the build script and the IDE settings.
--
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
16 years, 3 months
[JBoss JIRA] Assigned: (JBREM-924) Compilation errors in non ISO-8859-1 systems
by David Lloyd (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-924?page=all ]
David Lloyd reassigned JBREM-924:
---------------------------------
Assignee: David Lloyd
> Compilation errors in non ISO-8859-1 systems
> --------------------------------------------
>
> Key: JBREM-924
> URL: http://jira.jboss.com/jira/browse/JBREM-924
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.4.0.Beta1 (Pinto)
> Environment: Fedora 8, LANG=ko_KR.UTF-8
> Reporter: Trustin Lee
> Assigned To: David Lloyd
> Priority: Trivial
> Fix For: 2.4.0.CR1 (Pinto)
>
> Attachments: remoting2-encoding.diff
>
>
> The default encoding of my machine is UTF-8, but it seems like Remoting 2 trunk source code is encoded in ISO-8859-1. When I run 'ant tests', it bails out with a compilation error that there's a unmappable character in the source code. The solution of this problem is to specify the encoding of the source code explicitly in the build script and the IDE settings.
--
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
16 years, 3 months
[JBoss JIRA] Commented: (JBREM-920) Create build.xml target to run test suite with a Security Manager
by David Lloyd (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-920?page=comments#action_12401819 ]
David Lloyd commented on JBREM-920:
-----------------------------------
Committed - for better or worse :-)
All functional tests are now running with a security manager. I haven't enabled it for the stress tests though. I'm leaving this open in the (likely) event that this somehow breaks Hudson test runs or something.
> Create build.xml target to run test suite with a Security Manager
> -----------------------------------------------------------------
>
> Key: JBREM-920
> URL: http://jira.jboss.com/jira/browse/JBREM-920
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Ron Sigal
> Assigned To: David Lloyd
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> From Anil Saldana:
> Presuming that you have a test suite and either use ANT or Maven, I
> recommend an extra target to run the test suite in a Java Security
> Manager with minimal permissions. So for ANT, you will have an
> additional target. For MAVEN, you can use a profile.
> The idea is that you have a Java Security Policy file in which you
> provide unlimited permission to third party libraries and minimal
> permissions to your own code. This exercise is to detect critical
> sections of code that need special privileges and get into privileged
> blocks. If you have an extra target for the security manager and your
> test runs happen on hudson, you can detect issues with security manager
> as new code gets added.
> Please do not have one test that does System.setSecurityManager but run
> your entire test suite via the security manager
> (-Djava.security.manager -Djava.security.policy=somefile).
> Example: (Take a look by clicking "Configure" on the LHS)
> http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/
> http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s...
> Now if your head is spinning or you do not care about security or do not
> have the time to do it, please tell me. I can engage myself, someone
> from JBoss Security Team or the QA person handling your project to add a
> JIRA issue (and make the build.xml/pom.xml changes for your project).
> Why is this important?
> * Because many customers run JBAS in a security manager and we need to
> detect issues in our own code. Also during a recent integration work
> with JBoss Messaging for the SOA platform, there was one issue with
> remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is
> still reeling). It took some cycles from me also.
> * We need to have tests running in a security manager on an ongoing basis.
> I understand that there are resource issues in various projects. But
> that does not discount the work that we need to do before we ship JBAS. ;)
--
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
16 years, 3 months
[JBoss JIRA] Assigned: (JBREM-920) Create build.xml target to run test suite with a Security Manager
by David Lloyd (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-920?page=all ]
David Lloyd reassigned JBREM-920:
---------------------------------
Assignee: David Lloyd
> Create build.xml target to run test suite with a Security Manager
> -----------------------------------------------------------------
>
> Key: JBREM-920
> URL: http://jira.jboss.com/jira/browse/JBREM-920
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Ron Sigal
> Assigned To: David Lloyd
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> From Anil Saldana:
> Presuming that you have a test suite and either use ANT or Maven, I
> recommend an extra target to run the test suite in a Java Security
> Manager with minimal permissions. So for ANT, you will have an
> additional target. For MAVEN, you can use a profile.
> The idea is that you have a Java Security Policy file in which you
> provide unlimited permission to third party libraries and minimal
> permissions to your own code. This exercise is to detect critical
> sections of code that need special privileges and get into privileged
> blocks. If you have an extra target for the security manager and your
> test runs happen on hudson, you can detect issues with security manager
> as new code gets added.
> Please do not have one test that does System.setSecurityManager but run
> your entire test suite via the security manager
> (-Djava.security.manager -Djava.security.policy=somefile).
> Example: (Take a look by clicking "Configure" on the LHS)
> http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/
> http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s...
> Now if your head is spinning or you do not care about security or do not
> have the time to do it, please tell me. I can engage myself, someone
> from JBoss Security Team or the QA person handling your project to add a
> JIRA issue (and make the build.xml/pom.xml changes for your project).
> Why is this important?
> * Because many customers run JBAS in a security manager and we need to
> detect issues in our own code. Also during a recent integration work
> with JBoss Messaging for the SOA platform, there was one issue with
> remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is
> still reeling). It took some cycles from me also.
> * We need to have tests running in a security manager on an ongoing basis.
> I understand that there are resource issues in various projects. But
> that does not discount the work that we need to do before we ship JBAS. ;)
--
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
16 years, 3 months
[JBoss JIRA] Work started: (JBREM-901) can't start NetworkRegistry if hostname is not resolvable
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-901?page=all ]
Work on JBREM-901 started by Ron Sigal.
> can't start NetworkRegistry if hostname is not resolvable
> ---------------------------------------------------------
>
> Key: JBREM-901
> URL: http://jira.jboss.com/jira/browse/JBREM-901
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.2.1.GA
> Reporter: John Mazzitelli
> Assigned To: Ron Sigal
> Priority: Minor
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> Suppose I have a box whose hostname is not resolvable via DNS (I know, I know, but for people demo'ing software on a laptop, we've seen it happen). So, I cannot "ping `hostname`" but I can "ping 127.0.0.1".
> Look at NetworkRegistry:
> public ObjectName preRegister(MBeanServer mBeanServer, ObjectName objectName) throws Exception
> {
> this.mBeanServer = mBeanServer;
> this.objectName = objectName;
> // make sure our identity system property is properly set
> Identity identity = Identity.get(this.mBeanServer);
> ...
> Now look at the Identity.get() method it called there:
> if(identities.containsKey(server))
> {
> return (Identity) identities.get(server);
> }
> try
> {
> String serverid = (String) server.getAttribute(new ObjectName("JMImplementation:type=MBeanServerDelegate"), "MBeanServerId");
> Identity identity = new Identity(InetAddress.getLocalHost(), createId(server), serverid);
> identities.put(server, identity);
> return identity;
> }
> It calls InetAddress.getLocalHost() but if that fails (and it will if the local hostname is not resolvable) you can *never* start a NetworkRegistry object.
> If there is an exception here in that call to InetAddress.getLocalHost(), it should fallback and use: InetAddress getByName("127.0.0.1").
> I tried setting "jboss.identity" sysprop to Identity.createUniqueID() but unfortunately, that sysprop isn't used in this class and NetworkRegistry never looks to see if that is set as a fallback.
> I understand that without a resolvable host, it hobbles things - but for demo purposes of software that will ONLY ever run on a single laptop over the loopback network adapter on 127.0.0.1, this should still work without me having to disable things like the NetworkRegistry.
--
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
16 years, 3 months
[JBoss JIRA] Work started: (JBREM-826) JBoss Remoting logs at ERROR and WARN in many places
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-826?page=all ]
Work on JBREM-826 started by Ron Sigal.
> JBoss Remoting logs at ERROR and WARN in many places
> ----------------------------------------------------
>
> Key: JBREM-826
> URL: http://jira.jboss.com/jira/browse/JBREM-826
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Tim Fox
> Assigned To: Ron Sigal
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> In many places JBoss Remoting logs at ERROR or WARN which seem inappropriate.
> JBR is a toolkit and should not log errors it does not handle.
> There is a general principle of you shouldn't log unless you handle the error. If you just pass it up, don't log. This principle is adhered to in JBoss AS for example, and IMHO should be used throughout all JBoss projects. If every toolkit being used in the chain logged the same error then you end up with a complete mess in the logs every time an exception occurs.
> Failover in JBoss Messaging is a good example.
> In JBM we detect failure of the remoting connection via the connection listener, and transparently reconnect on a different node. In this case, from the users POV *no error* has occurred - the process should be completely seamless.
> However JBoss Remoting spews a load of exceptions to the logs at ERROR and WARN, for example:
> SERVER 1 STDOUT: @RMI TCP Connection(2)-127.0.0.1 08:27:29,571 INFO [RMITestServer] kill() invoked - first deregistering from the rmi registry
> SERVER 1 STDOUT: @RMI TCP Connection(2)-127.0.0.1 08:27:29,572 INFO [RMITestServer] unregistered messaging_rmi_server_1 from registry
> SERVER 1 STDOUT: @RMI TCP Connection(2)-127.0.0.1 08:27:29,573 INFO [RMITestServer] unregistered naming_rmi_server_1 from registry
> SERVER 1 STDOUT: @RMI TCP Connection(2)-127.0.0.1 08:27:29,573 INFO [RMITestServer] Killing VM!!!!
> @main 08:27:29,940 INFO [ServerManagement] Waiting for server to die
> SERVER 0 STDOUT: @Timer-4 08:27:30,084 ERROR [SocketClientInvoker] Got marshalling exception, exiting
> SERVER 0 STDOUT: java.net.SocketException: end of file
> SERVER 0 STDOUT: at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:577)
> SERVER 0 STDOUT: at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413)
> SERVER 0 STDOUT: at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> SERVER 0 STDOUT: at org.jboss.remoting.ConnectionValidator.doCheckConnection(ConnectionValidator.java:133)
> SERVER 0 STDOUT: at org.jboss.remoting.ConnectionValidator.run(ConnectionValidator.java:308)
> SERVER 0 STDOUT: at java.util.TimerThread.mainLoop(Timer.java:512)
> SERVER 0 STDOUT: at java.util.TimerThread.run(Timer.java:462)
> @main 08:27:30,241 INFO [ServerManagement] server 1 killed and dead
> @Timer-3 08:27:30,275 ERROR [SocketClientInvoker] Got marshalling exception, exiting
> java.net.SocketException: end of file
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:577)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> at org.jboss.remoting.ConnectionValidator.doCheckConnection(ConnectionValidator.java:133)
> at org.jboss.remoting.ConnectionValidator.run(ConnectionValidator.java:308)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> @Thread-9 08:27:30,318 WARN [Client] unable to remove remote callback handler: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2840/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat]
> @Thread-9 08:27:30,338 WARN [LeasePinger] LeasePinger[SocketClientInvoker[53ab04, bisocket://localhost:2840](3j001-c12qds-f8e5pqu9-1-f8e5pqwg-3)] failed sending disconnect for client lease for client with session ID 3j001-c12qds-f8e5pqu9-1-f8e5pqua-2
> @Thread-9 08:27:30,360 WARN [LeasePinger] LeasePinger[SocketClientInvoker[53ab04, bisocket://localhost:2840](3j001-c12qds-f8e5pqu9-1-f8e5pqwg-3)] failed to ping to server: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2840/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat]
> @Thread-10 08:27:30,532 WARN [Client] unable to remove remote callback handler: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2840/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat]
> @Thread-10 08:27:30,551 WARN [LeasePinger] LeasePinger[SocketClientInvoker[53ab04, bisocket://localhost:2840](3j001-c12qds-f8e5pqu9-1-f8e5pqwg-3)] failed sending disconnect for client lease for client with session ID 3j001-c12qds-f8e5pqu9-1-f8e5pss1-9
> @Thread-10 08:27:30,570 WARN [LeasePinger] LeasePinger[SocketClientInvoker[53ab04, bisocket://localhost:2840](3j001-c12qds-f8e5pqu9-1-f8e5pqwg-3)] failed to ping to server: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2840/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat]
> @Thread-9 08:27:30,600 ERROR [BisocketServerInvoker] unable to get secondary locator
> org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2840/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat]
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:532)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.getSecondaryLocator(BisocketClientInvoker.java:538)
> at org.jboss.remoting.transport.bisocket.BisocketServerInvoker.createControlConnection(BisocketServerInvoker.java:228)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:402)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> at org.jboss.remoting.Client.invoke(Client.java:1634)
> at org.jboss.remoting.Client.addCallbackListener(Client.java:1703)
> at org.jboss.remoting.Client.addListener(Client.java:921)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.addInvokerCallbackHandler(JMSRemotingConnection.java:237)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:312)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.establishCallback(ClientClusteredConnectionFactoryDelegate.java:99)
> at org.jboss.jms.client.remoting.ConnectionFactoryCallbackHandler$CallbackConnectionListener.handleConnectionException(ConnectionFactoryCallbackHandler.java:105)
> at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:452)
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:519)
> at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:187)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket(BisocketClientInvoker.java:420)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:815)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:525)
> ... 14 more
> @Thread-9 08:27:30,620 WARN [Client] unable to remove remote callback handler: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2840/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat]
> @Thread-9 08:27:30,639 WARN [LeasePinger] LeasePinger[SocketClientInvoker[53ab04, bisocket://localhost:2840](3j001-c12qds-f8e5pqu9-1-f8e5pqwg-3)] failed sending disconnect for client lease for client with session ID 3j001-c12qds-f8e5pqu9-1-f8e5puat-k
> @Thread-10 08:27:30,760 ERROR [BisocketServerInvoker] unable to get secondary locator
> org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2840/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat]
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:532)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.getSecondaryLocator(BisocketClientInvoker.java:538)
> at org.jboss.remoting.transport.bisocket.BisocketServerInvoker.createControlConnection(BisocketServerInvoker.java:228)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:402)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> at org.jboss.remoting.Client.invoke(Client.java:1634)
> at org.jboss.remoting.Client.addCallbackListener(Client.java:1703)
> at org.jboss.remoting.Client.addListener(Client.java:921)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.addInvokerCallbackHandler(JMSRemotingConnection.java:237)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:312)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.establishCallback(ClientClusteredConnectionFactoryDelegate.java:99)
> at org.jboss.jms.client.remoting.ConnectionFactoryCallbackHandler$CallbackConnectionListener.handleConnectionException(ConnectionFactoryCallbackHandler.java:105)
> at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:452)
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:519)
> at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:187)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket(BisocketClientInvoker.java:420)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:815)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:525)
> ... 14 more
> @Thread-10 08:27:30,780 WARN [Client] unable to remove remote callback handler: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2840/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat]
> @Thread-10 08:27:30,807 WARN [LeasePinger] LeasePinger[SocketClientInvoker[53ab04, bisocket://localhost:2840](3j001-c12qds-f8e5pqu9-1-f8e5pqwg-3)] failed sending disconnect for client lease for client with session ID 3j001-c12qds-f8e5pqu9-1-f8e5pugn-p
> @Thread-13 08:27:31,491 INFO [FailoverCommandCenter] JBoss Messaging server failure detected - waiting for failover to complete...
> @Thread-13 08:27:31,793 ERROR [SocketClientInvoker] Got marshalling exception, exiting
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:168)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
> at java.io.FilterInputStream.read(FilterInputStream.java:66)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.readVersion(MicroSocketClientInvoker.java:1000)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:574)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> at org.jboss.remoting.LeasePinger.sendClientPing(LeasePinger.java:283)
> at org.jboss.remoting.LeasePinger.addClient(LeasePinger.java:117)
> at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:358)
> at org.jboss.remoting.Client.setupClientLease(Client.java:1625)
> at org.jboss.remoting.Client.connect(Client.java:1525)
> at org.jboss.remoting.Client.connect(Client.java:462)
> at org.jboss.jms.client.remoting.JMSRemotingConnection$1.run(JMSRemotingConnection.java:295)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:291)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:154)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:83)
> at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> at org.jboss.jms.client.container.ClusteringAspect.handleCreateConnectionDelegate(ClusteringAspect.java:134)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientClusteredConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.createConnectionDelegate(ClientClusteredConnectionFactoryDelegate.java)
> at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:129)
> at org.jboss.jms.client.container.ConnectionFailureListener.handleConnectionException(ConnectionFailureListener.java:62)
> at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:81)
> at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:452)
> @Thread-13 08:27:31,801 WARN [LeasePinger] LeasePinger[SocketClientInvoker[682406, bisocket://localhost:2854](3j001-c12qds-f8e5pqu9-1-f8e5puj4-v)] failed to ping to server: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is:
> java.net.SocketException: Connection reset
> @Thread-2 08:27:31,820 ERROR [SocketClientInvoker] Got marshalling exception, exiting
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:168)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
> at java.io.FilterInputStream.read(FilterInputStream.java:66)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.readVersion(MicroSocketClientInvoker.java:1000)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:574)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> at org.jboss.remoting.Client.invoke(Client.java:1634)
> at org.jboss.remoting.Client.invoke(Client.java:548)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.removeCallback(ClientClusteredConnectionFactoryDelegate.java:152)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.closeCallback(ClientClusteredConnectionFactoryDelegate.java:168)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.finalize(ClientClusteredConnectionFactoryDelegate.java:158)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate$FinalizerShutdownHook.run(ClientClusteredConnectionFactoryDelegate.java:418)
> @Thread-2 08:27:31,839 WARN [Client] unable to remove remote callback handler: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2854/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=fals
> This completely messes up the logs and the customer believes something has gone wrong, phones support and they waste a lot of time trying to work out what the problem is, when actually there is no problem and this is perfectly successful failover from one node to another, but to the customer they have a flawed experience.
> The customer says "Why was JBoss reporting errors when everything was ok?"
> If anything is to be logged in these cases it should be at DEBUG level at the highest, so it can be easily supressed in the standard log4j config.
> In the mean-time if you could provide a log4j config which supresses these messages for the specific classes so they don't appear even on ERROR level that would be much appreciated.
--
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
16 years, 3 months
[JBoss JIRA] Updated: (JBREM-901) can't start NetworkRegistry if hostname is not resolvable
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-901?page=all ]
Ron Sigal updated JBREM-901:
----------------------------
Assignee: Ron Sigal
> can't start NetworkRegistry if hostname is not resolvable
> ---------------------------------------------------------
>
> Key: JBREM-901
> URL: http://jira.jboss.com/jira/browse/JBREM-901
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.2.1.GA
> Reporter: John Mazzitelli
> Assigned To: Ron Sigal
> Priority: Minor
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> Suppose I have a box whose hostname is not resolvable via DNS (I know, I know, but for people demo'ing software on a laptop, we've seen it happen). So, I cannot "ping `hostname`" but I can "ping 127.0.0.1".
> Look at NetworkRegistry:
> public ObjectName preRegister(MBeanServer mBeanServer, ObjectName objectName) throws Exception
> {
> this.mBeanServer = mBeanServer;
> this.objectName = objectName;
> // make sure our identity system property is properly set
> Identity identity = Identity.get(this.mBeanServer);
> ...
> Now look at the Identity.get() method it called there:
> if(identities.containsKey(server))
> {
> return (Identity) identities.get(server);
> }
> try
> {
> String serverid = (String) server.getAttribute(new ObjectName("JMImplementation:type=MBeanServerDelegate"), "MBeanServerId");
> Identity identity = new Identity(InetAddress.getLocalHost(), createId(server), serverid);
> identities.put(server, identity);
> return identity;
> }
> It calls InetAddress.getLocalHost() but if that fails (and it will if the local hostname is not resolvable) you can *never* start a NetworkRegistry object.
> If there is an exception here in that call to InetAddress.getLocalHost(), it should fallback and use: InetAddress getByName("127.0.0.1").
> I tried setting "jboss.identity" sysprop to Identity.createUniqueID() but unfortunately, that sysprop isn't used in this class and NetworkRegistry never looks to see if that is set as a fallback.
> I understand that without a resolvable host, it hobbles things - but for demo purposes of software that will ONLY ever run on a single laptop over the loopback network adapter on 127.0.0.1, this should still work without me having to disable things like the NetworkRegistry.
--
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
16 years, 3 months
[JBoss JIRA] Commented: (JBREM-901) can't start NetworkRegistry if hostname is not resolvable
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-901?page=comments#action_12401715 ]
Ron Sigal commented on JBREM-901:
---------------------------------
Changed org.jboss.remoting.ident.Identity.get() to
public static synchronized final Identity get(MBeanServer server)
{
if(identities.containsKey(server))
{
return (Identity) identities.get(server);
}
try
{
InetAddress localHost = null;
try
{
localHost = InetAddress.getLocalHost();
}
catch (IOException e)
{
localHost = InetAddress.getByName("127.0.0.1");
}
String serverid = (String) server.getAttribute(new ObjectName("JMImplementation:type=MBeanServerDelegate"), "MBeanServerId");
Identity identity = new Identity(localHost, createId(server), serverid);
identities.put(server, identity);
return identity;
}
catch(Exception ex)
{
String type = ex.getClass().getName();
final RuntimeException rex = new RuntimeException("Exception creating identity: " + type + ": " + ex.getMessage());
rex.setStackTrace(ex.getStackTrace());
throw rex;
}
}
There are no specific unit tests, but will check for new failures in hudson.
> can't start NetworkRegistry if hostname is not resolvable
> ---------------------------------------------------------
>
> Key: JBREM-901
> URL: http://jira.jboss.com/jira/browse/JBREM-901
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.2.1.GA
> Reporter: John Mazzitelli
> Priority: Minor
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> Suppose I have a box whose hostname is not resolvable via DNS (I know, I know, but for people demo'ing software on a laptop, we've seen it happen). So, I cannot "ping `hostname`" but I can "ping 127.0.0.1".
> Look at NetworkRegistry:
> public ObjectName preRegister(MBeanServer mBeanServer, ObjectName objectName) throws Exception
> {
> this.mBeanServer = mBeanServer;
> this.objectName = objectName;
> // make sure our identity system property is properly set
> Identity identity = Identity.get(this.mBeanServer);
> ...
> Now look at the Identity.get() method it called there:
> if(identities.containsKey(server))
> {
> return (Identity) identities.get(server);
> }
> try
> {
> String serverid = (String) server.getAttribute(new ObjectName("JMImplementation:type=MBeanServerDelegate"), "MBeanServerId");
> Identity identity = new Identity(InetAddress.getLocalHost(), createId(server), serverid);
> identities.put(server, identity);
> return identity;
> }
> It calls InetAddress.getLocalHost() but if that fails (and it will if the local hostname is not resolvable) you can *never* start a NetworkRegistry object.
> If there is an exception here in that call to InetAddress.getLocalHost(), it should fallback and use: InetAddress getByName("127.0.0.1").
> I tried setting "jboss.identity" sysprop to Identity.createUniqueID() but unfortunately, that sysprop isn't used in this class and NetworkRegistry never looks to see if that is set as a fallback.
> I understand that without a resolvable host, it hobbles things - but for demo purposes of software that will ONLY ever run on a single laptop over the loopback network adapter on 127.0.0.1, this should still work without me having to disable things like the NetworkRegistry.
--
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
16 years, 3 months
[JBoss JIRA] Closed: (JBREM-698) Update Remoting Marshaller/UnMarshallers to implement PreferredStreamMarshaller/PreferredStreamUnMarshaller interfaces.
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-698?page=all ]
Ron Sigal closed JBREM-698.
---------------------------
Resolution: Done
* compressing marshaller/unmarshaller:
org.jboss.remoting.marshal.compress.CompressingMarshaller and org.jboss.remoting.marshal.compress.CompressingUnMarshaller override getMarshallingStream() inherited from org.jboss.remoting.marshal.serializable.SerializableMarshaller and org.jboss.remoting.marshal.serializable.SerializableUnMarshaller, so that, instead of returning object streams, they return the original streams (socket streams) unchanged.
* encrypting marshaller/unmarshaller:
Same as compressing marshaller/unmarshaller.
* http marshaller/unmarshaller:
org.jboss.remoting.marshal.http.HTTPMarshaller and org.jboss.remoting.marshal.http.HTTPUnMarshaller are derived from SerializableMarshaller and SerializableUnMarshallerf, and they inherit the getMarshallingStream() methods. When the data is in binary form, they simply call the inherited write()/read() methods, which use object streams. Otherwise, they use methods contained in the OutputStream/InputStream classes
There are no new unit tests..
> Update Remoting Marshaller/UnMarshallers to implement PreferredStreamMarshaller/PreferredStreamUnMarshaller interfaces.
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: JBREM-698
> URL: http://jira.jboss.com/jira/browse/JBREM-698
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 2.4.0.Beta1 (Pinto)
> Reporter: Ron Sigal
> Assigned To: Ron Sigal
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> In response to JBREM-692 the org.jboss.remoting.marshal.PreferredStreamMarshaller and org.jboss.remoting.marshal.PreferredStreamUnMarshaller interfaces were introduced, and org.jboss.remoting.marshal.serializable.SerializableMarshaller and org.jboss.remoting.marshal.serializable.SerializableUnMarshaller were modified to implement them. In particular, they implement a getMarshallingStream() method which returns an object stream that can be cached and reused by the transport layer.
> Now, the other Remoting marshallers (http, compressing, encrypting) should also be made to implement those interfaces.
--
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
16 years, 3 months