openejb.xml: <?xml version="1.0" encoding="UTF-8"?> <openejb>
<Container id="My Singleton Container" type="SINGLETON"> # Specifies the maximum time an invocation could wait for the # singleton bean instance to become available before giving up. # # After the timeout is reached a javax.ejb.ConcurrentAccessTimeoutException # will be thrown. # # Usable time units: nanoseconds, microsecons, milliseconds, # seconds, minutes, hours, days. Or any combination such as # "1 hour and 27 minutes and 10 seconds" AccessTimeout = 30 seconds </Container> <Container id="My Stateful Container" type="STATEFUL"> # Specifies the maximum time an invocation could wait for the # stateful bean instance to become available before giving up. # # After the timeout is reached a javax.ejb.ConcurrentAccessTimeoutException # will be thrown. # # Usable time units: nanoseconds, microsecons, milliseconds, # seconds, minutes, hours, days. Or any combination such as # "1 hour and 27 minutes and 10 seconds" AccessTimeout = 30 seconds # The passivator is responsible for writing beans to disk # at passivation time. Different passivators can be used # by setting this property to the fully qualified class name # of the PassivationStrategy implementation. The passivator # is not responsible for invoking any callbacks or other # processing, its only responsibly is to write the bean state # to disk. # # Known implementations: # org.apache.openejb.core.stateful.RAFPassivater # org.apache.openejb.core.stateful.SimplePassivater Passivator org.apache.openejb.core.stateful.SimplePassivater # Specifies the time to wait between invocations. This # value is measured in minutes. A value of 5 would # result in a time-out of 5 minutes between invocations. # A value of zero would mean no timeout. TimeOut 20 # Specifies the frequency (in seconds) at which the bean cache is checked for # idle beans. Frequency 60 # Specifies the size of the bean pools for this # stateful SessionBean container. Capacity 1000 # Property name that specifies the number of instances # to passivate at one time when doing bulk passivation. # Must be less than the PoolSize. BulkPassivate 100 </Container> <Container id="My Stateless Container" type="STATELESS"> # Specifies the time an invokation should wait for an instance # of the pool to become available. # # After the timeout is reached, if an instance in the pool cannot # be obtained, the method invocation will fail. # # Usable time units: nanoseconds, microsecons, milliseconds, # seconds, minutes, hours, days. Or any combination such as # "1 hour and 27 minutes and 10 seconds" AccessTimeout = 30 seconds # Specifies the size of the bean pools for this stateless # SessionBean container. If StrictPooling is not used, instances # will still be created beyond this number if there is demand, but # they will not be returned to the pool and instead will be # immediately destroyed. MaxSize = 10 # Specifies the minimum number of bean instances that should be in # the pool for each bean. Pools are prefilled to the minimum on # startup. Note this will create start order dependencies between # other beans that also eagerly start, such as other @Stateless # beans with a minimum or @Singleton beans using @Startup. The # @DependsOn annotation can be used to appropriately influence # start order. # # The minimum pool size is rigidly maintained. Instances in the # minimum side of the pool are not eligible for IdleTimeout or # GarbageCollection, but are subject to MaxAge and flushing. # # If the pool is flushed it is immediately refilled to the minimum # size with MaxAgeOffset applied. If an instance from the minimum # side of the pool reaches its MaxAge, it is also immediately # replaced. Replacement is done in a background queue using the # number of threads specified by CallbackThreads. MinSize = 0 # StrictPooling tells the container what to do when the pool # reaches it's maximum size and there are incoming requests that # need instances. # # With strict pooling, requests will have to wait for instances to # become available. The pool size will never grow beyond the the # set MaxSize value. The maximum amount of time a request should # wait is specified via the AccessTimeout setting. # # Without strict pooling, the container will create temporary # instances to meet demand. The instances will last for just one # method invocation and then are removed. # # Setting StrictPooling to false and MaxSize to 0 will result in # no pooling. Instead instances will be created on demand and live # for exactly one method call before being removed. StrictPooling = true # Specifies the maximum time that an instance should live before # it should be retired and removed from use. This will happen # gracefully. Useful for situations where bean instances are # designed to hold potentially expensive resources such as memory # or file handles and need to be periodically cleared out. # # Usable time units: nanoseconds, microsecons, milliseconds, # seconds, minutes, hours, days. Or any combination such as # "1 hour and 27 minutes and 10 seconds" MaxAge = 0 hours # Specifies the maximum time that an instance should be allowed to # sit idly in the pool without use before it should be retired and # removed. # # Usable time units: nanoseconds, microsecons, milliseconds, # seconds, minutes, hours, days. Or any combination such as # "1 hour and 27 minutes and 10 seconds" IdleTimeout = 0 minutes </Container> <!-- # For more examples of database configuration see: # http://openejb.apache.org/containers-and-resources.html --> <Resource id="My DataSource" type="DataSource"> JdbcDriver org.hsqldb.jdbcDriver JdbcUrl jdbc:hsqldb:file:data/hsqldb/hsqldb UserName sa Password JtaManaged true </Resource> <Resource id="My Unmanaged DataSource" type="DataSource"> JdbcDriver org.hsqldb.jdbcDriver JdbcUrl jdbc:hsqldb:file:data/hsqldb/hsqldb UserName sa Password JtaManaged false </Resource> <Resource id="MyJmsResourceAdapter" type="ActiveMQResourceAdapter"> BrokerXmlConfig broker:(tcp://localhost:61616)?useJmx=true # Broker address ServerUrl vm://localhost?async=true #Broker configuration URI as defined by ActiveMQ #see http://activemq.apache.org/broker-configuration-uri.html #BrokerXmlConfig = broker:(tcp://localhost:61616) #Broker address #ServerUrl = tcp://localhost:61616 </Resource> <Resource id="ConnectionFactory" type="javax.jms.ConnectionFactory"> ResourceAdapter = MyJmsResourceAdapter </Resource> <Container id="MyJmsMdbContainer" type="MESSAGE"> ResourceAdapter = MyJmsResourceAdapter </Container> <Resource id="answerQueue" type="javax.jms.Queue"/> <Resource id="askTopic" type="javax.jms.Topic"/> <Resource id="jms/MyTopic" type="javax.jms.Topic"> destination MyTopic </Resource> <!-- #broker:(tcp://0.0.0.0:61616) # # The <Deployments> element can be used to configure file # paths where OpenEJB should look for ejb jars or ear files. # # See http://openejb.apache.org/3.0/deployments.html # # The below entry is simply a default and can be changed or deleted --> <Deployments dir="apps/" /> </openejb> On 25 Şub 2013, at 11:43, Sule BASOL <[email protected]> wrote: > > Okay , another problem is , i m also using activemq server. > I want same thing for activemq too please.OpenEJB with activeMQ is always > used. > I cant get the ip address of the discovered server.So , i cant connect to > activemq server. > Because dynamic ip's here.... > > > > On 25 Şub 2013, at 10:49, AndyG <[email protected]> wrote: > >> In trunk (4.6 snapshot at the time of writing) there is now the option to >> 'ignore' hosts in the multipulse.properties. >> >> The original desire for MultiPulse was a virtually zero configuration for >> discovery of multi-homed systems. For example some of my server machines >> ship with up to 5 Ethernet cameras that use DHCP, a regular LAN and possibly >> several virtual IPs. MultiPulse pulses the entire discovered host list, and >> lets the client work out which hosts are good to go. The pulse actually goes >> out on all interfaces, so not even the server needs to 'know' it's LAN/bind >> address. >> >> However, if you are not lazy like me then you can modify the >> multipulse.properties file and add known unreachable hosts to the ignore >> parameter: >> >> ignore = [2002:5eba:a72a:0:f560:dda3:93ba:f7e5],SPECTRUM-SRV >> >> The client will then (based upon the previously discovered list) only try to >> connect to 10.0.1.7 - This is actually not going to improve performance here >> because it was already first in the list. A MultiPulse client will return >> the first reachable connection. You get the idea though. >> >> Andy. >> >> >> >> -- >> View this message in context: >> http://openejb.979440.n4.nabble.com/slow-multicast-discovery-can-be-optimized-by-caching-server-tp4660726p4661008.html >> Sent from the OpenEJB Dev mailing list archive at Nabble.com. > and activemq with openejb ip swing client discovery problem is: ctxProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.activemq.jndi.ActiveMQInitialContextFactory"); ctxProps.put(Context.PROVIDER_URL, "??? dont know the dynamic ip"); < = whats the discovered ip activemq doesnt have multipulse support ? Its same same server with openejb prop.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory"); prop.put(Context.PROVIDER_URL, "multipulse://239.255.2.3:6142?group=default&timeout=250"); queueContext = new InitialContext(ctxProps); openejbContext = new InitialContext(prop);
