[Remoting] - Re: Problem calling EJB3 method via HTTP only
by ron.sigal＠jboss.com
1. The JBoss naming service, which implements JNDI, doesn't use Remoting, so the exception
| Exception in thread "main" javax.naming.CommunicationException: Operation failed [Root exception is java.rmi.ServerException:
| IOE; nested exception is:
| java.net.ConnectException: Connection refused: connect]
| at org.jboss.naming.interceptors.ExceptionInterceptor.invoke(ExceptionInterceptor.java:65)
|
is not related to Remoting. For help with the naming service, I would suggest the "JNDI/Naming/Network" forum.
2.
anonymous wrote :
| So actually, do i need ejb over http/s???
|
I'm not sure how to answer that. A typical reason for using http for EJB invocations would be to avoid firewall problems. Otherwise, you could use the standard EJB3 setup and the client would communicate directly with the EJB implementation, without going through a web server.
3. For more information about Tomcat, I'd suggest http://tomcat.apache.org/findhelp.html.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084702#4084702
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084702
18 years, 9 months
[Remoting] - Re: CompressingMarshaller and clientConnectAddress
by ron.sigal＠jboss.com
There are two options:
1. You can append the clientConnectAddress parameter to the InvokerLocator:
| <attribute name="InvokerLocator">socket://${jboss.bind.address}:3873/?marshaller=org.jboss.remoting.marshal.compress.CompressingMarsh
| aller&unmarshaller=org.jboss.remoting.marshal.compress.CompressingUnMarsh...</attribute>
|
or you can add attribute elements for the marshaller and unmarshaller to the invoker element:
| <mbean code="org.jboss.remoting.transport.Connector" name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
| <depends>jboss.aop:service=AspectDeployer</depends>
| <attribute name="Configuration">
| <config>
| <invoker transport="socket">
| <attribute name="numAcceptThreads">1</attribute>
| <attribute name="maxPoolSize">360</attribute>
| <attribute name="clientMaxPoolSize" isParam="true">50</attribute>
| <attribute name="timeout" isParam="true">60000</attribute>
| <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
| <attribute name="serverBindPort">3873</attribute>
| <attribute name="clientConnectAddress">
| ###THE_CLIENT_CONNECT_ADDRESS###</attribute>
| <attribute name="backlog">200</attribute>
| <attribute name="marshaller">org.jboss.remoting.marshal.compress.CompressingMarshaller</attribute>
| <attribute name="unmarshaller">org.jboss.remoting.marshal.compress.CompressingUnMarshaller</attribute>
| </invoker>
| <handlers>
| <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
| </handlers>
| </config>
| </attribute>
| </mbean>
|
See Section 5.1.1.2. "Declarative configuration" of the Remoting Guide (http://labs.jboss.com/jbossremoting/docs/guide/index.html).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084692#4084692
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084692
18 years, 9 months
[Remoting] - Re: MulticastDetector could not be loaded because the Networ
by ron.sigal＠jboss.com
In the Remoting detection facility, there are two kinds of detectors: client detectors and server detectors. Note that these should not be confused with client invokers and server invokers.
A server detector is responsible for publishing the existence of all server invokers running in the same JVM. A client detector will, in addition, keep track of all server invokers that it has detected, and when it notices the appearance of a new server invoker or the disappearance of a known server invoker, it will notify all registered listeners of the change in the network.
Notifying listeners of network changes is performed by an org.jboss.remoting.network.NetworkRegistry. A detector queries its MBeanServer to retrieve a NetworkRegistry, but if none is available, it is unable to make notifications. In other words, if a detector cannot locate a NetworkRegistry, it is, by definition, a server detector. The message
anonymous wrote :
| Detector: org.jboss.remoting.detection.multicast.MulticastDetector could not be loaded because the NetworkRegistry is not registered
| This means that only the broadcasting of detection messages will be functional and will not be able to discover other servers.
|
means that you did not register a NetworkRegistry with the MBeanServer and listeners will not be informed of the discovery of new servers (or the disappearance of old ones).
For an example of how to set up detection, see the classes org.jboss.remoting.samples.detection.multicast.SimpleDetectorClient and org.jboss.remoting.samples.detection.multicast.SimpleDetectorServer in the Remoting source code tree.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084689#4084689
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084689
18 years, 9 months