[JBoss Messaging Development] - JBM 1.4.4 dynamic port/firewall issue
by belcar
Hi All
I'm trying to access a JBM 1.4.4. environment deployed on JBoss 4.2.3 from a remote JBoss 4.2.3 server (client). The messaging client server is behind a firewall.
We've opened following ports on the firewall: 1099, 1098, 4444 and 4457.
Apparently we needed to open an additional undocumented port (55794) in order to let the client code create the JMS connection and ask for a JMS Session.
However, for some reason the client code that tries to open a JMS connection seems to use dynamic ports. Some time later on (after some restarts) the client tries to access port 17661 on the JBM machine (instead of 55794). This leads to a process freeze.
Is there a configuration option so we can fix this port and/or can somebody please explain what is going on?
Thanks in advance for your reply.
Greetz
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257595#4257595
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257595
15 years, 3 months
[JBoss Transactions Development] - Re: Asynchronicity and transaction context propagation
by chtimi2
Alright. The first step is to write a unit test that asserts checked transaction semantics.
1/ atomicitySync is the standard synchronous case, and passes
2/ atomicityAsync is the asynchronous case, and fails
I use JBoss Cache (core edition) as the transactional resource.
Now the goal is to make 2/ pass in steps:
-same test, same results, but using JBossTS (verify correct JBTS integration)
-set up JBossTS as explained in the previous post to make it pass
But first do you agree with my test?
Here is the test:
@RunWith(SpringJUnit4ClassRunner.class)
| @ContextConfiguration ( locations={"/application-context_Jdbc_Atomikos.xml"} )
| public class ComportementTransactionnelAsync implements ApplicationContextAware
| {
| private Cache cache;
| @Resource ( name="tracksTable" )
| protected TracksTable table;
| protected static ApplicationContext applicationContext;
|
| @Test
| //@Ignore
| public void atomicitySync () throws Exception
| {
| atomicity ( false );
| }
|
| @Test
| public void atomicityAsync () throws Exception
| {
| atomicity ( true );
| }
|
| private void atomicity ( boolean async ) throws Exception
| {
| final String A_OK="A", B_OK="B", A_KO="C" , B_KO="D";
| updateAB ( A_OK , B_OK , async , false );
| assertEquals ( A_OK , table.getA() );
| assertEquals ( B_OK , table.getB() );
|
| try
| {
| updateAB ( A_KO , B_KO , async , true );
| fail ();
| }
| catch ( Exception e ) {}
| finally
| {
| assertEquals ( B_OK , table.getB() );
| assertEquals ( A_OK , table.getA() );
| }
| }
|
| private void updateAB(String a, String b, boolean async, boolean failOnB) throws InterruptedException
| {
| table.updateAB ( a , b , async , failOnB );
| if ( async )
| {
| /* Commented since getA can be blocked by updateAB since IsolationLevel=Serializable
| * assertEquals ( "" , table.getA() ); //Transaction should not be committed yet
| assertEquals ( "" , table.getB() ); //Transaction should not be committed yet*/
|
| Thread.sleep(1500);
| }
| }
|
| @Before
| public void before ()
| {
| cache = createCoreCache ();
| cache.start();
| table.setCache ( cache );
|
| table.resetAB ();
| assertEquals ( "" , table.getA() );
| assertEquals ( "" , table.getB() );
| }
|
| @After
| public void stop ()
| {
| table.unsetCache ( cache );
| cache.stop();
| }
|
| private Cache createCoreCache()
| {
| CacheFactory factory = new DefaultCacheFactory();
| Cache cache = factory.createCache("resources/META-INF/replSync-service.xml", false);
|
| cache.getInvocationContext().getOptionOverrides().setForceSynchronous(true);
|
| cache.create();
| return cache;
| }
|
| @Override
| public void setApplicationContext(ApplicationContext applicationContext) throws BeansException
| {
| TransactionManager tm = (TransactionManager) applicationContext.getBean ( "atomikosTransactionManager" );
| AtomikosTransactionManagerLookup.setAtomikosTransactionManager ( tm );
| }
| }
And here is the service implementation:
@Service("tracksTable")
| @Transactional (propagation=Propagation.REQUIRED, isolation=Isolation.SERIALIZABLE, readOnly=false, timeout=10000)
| public class TracksTableImpl implements TracksTable
| {
| //--------------JBC-----------------
|
| private Cache coreCache;
|
| @Override
| public void updateAB ( String a , String b , boolean async , boolean failOnUpdateB )
| {
| setA ( a );
| Thread t = new Thread ( new SleepAndSetB ( b , failOnUpdateB ) );
| if ( async ) { t.start(); } else t.run();
| }
|
| private class SleepAndSetB implements Runnable
| {
| private final String b;
| private final boolean failOnUpdateB;
| SleepAndSetB ( String b, boolean failOnUpdateB ) { this.b = b; this.failOnUpdateB = failOnUpdateB; }
| @Override public void run()
| {
| ObjectUtils.sleep(500);
| if ( failOnUpdateB ) throw new TrackException ();
| setB ( b );
| }
| }
|
| @Override
| public String getA()
| {
| Node rootNode = coreCache.getRoot();
| return (String)rootNode.get ( "a" );
| }
|
| @Override
| public String getB()
| {
| Node rootNode = coreCache.getRoot();
| return (String)rootNode.get ( "b" );
| }
|
| private void setA ( String a )
| {
| System.out.println ( "setA [ a=" + a + " ]" );
| Node rootNode = coreCache.getRoot();
| rootNode.put ( "a" , a );
| }
|
| private void setB ( String b )
| {
| System.out.println ( "setB [ b=" + b + " ]" );
| Node rootNode = coreCache.getRoot();
| rootNode.put ( "b" , b );
| }
|
| @Override
| public void resetAB()
| {
| setA ( "" );
| setB ( "" );
| }
|
| @Override
| public void setCache ( Cache cache )
| {
| coreCache = cache;
| }
|
| @Override
| public void unsetCache ( Cache cache )
| {
| coreCache = null;
| }
| }
|
JBossCache conf (replSync-service.xml):
<?xml version="1.0" encoding="UTF-8"?>
| <server>
| <mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="jboss.cache:service=TreeCache">
|
| <attribute name="TransactionManagerLookupClass">hellotrackworld.impl.srv.AtomikosTransactionManagerLookup</attribute>
| <attribute name="NodeLockingScheme">PESSIMISTIC</attribute>
| <attribute name="IsolationLevel">SERIALIZABLE</attribute>
| <attribute name="CacheMode">LOCAL</attribute>
| <attribute name="UseReplQueue">false</attribute>
| <attribute name="ReplQueueInterval">0</attribute>
| <attribute name="ReplQueueMaxElements">0</attribute>
| <attribute name="ClusterName">JBossCache-Cluster</attribute>
|
| <attribute name="ClusterConfig">
| <config>
| <UDP mcast_addr="228.10.10.10"
| mcast_port="45588"
| tos="8"
| ucast_recv_buf_size="20000000"
| ucast_send_buf_size="640000"
| mcast_recv_buf_size="25000000"
| mcast_send_buf_size="640000"
| loopback="false"
| discard_incompatible_packets="true"
| max_bundle_size="64000"
| max_bundle_timeout="30"
| use_incoming_packet_handler="true"
| ip_ttl="2"
| enable_bundling="false"
| enable_diagnostics="true"
|
| use_concurrent_stack="true"
|
| thread_naming_pattern="pl"
|
| thread_pool.enabled="true"
| thread_pool.min_threads="1"
| thread_pool.max_threads="25"
| thread_pool.keep_alive_time="30000"
| thread_pool.queue_enabled="true"
| thread_pool.queue_max_size="10"
| thread_pool.rejection_policy="Run"
|
| oob_thread_pool.enabled="true"
| oob_thread_pool.min_threads="1"
| oob_thread_pool.max_threads="4"
| oob_thread_pool.keep_alive_time="10000"
| oob_thread_pool.queue_enabled="true"
| oob_thread_pool.queue_max_size="10"
| oob_thread_pool.rejection_policy="Run"/>
|
| <PING timeout="2000" num_initial_members="3"/>
| <MERGE2 max_interval="30000" min_interval="10000"/>
| <FD_SOCK/>
| <FD timeout="10000" max_tries="5" shun="true"/>
| <VERIFY_SUSPECT timeout="1500"/>
| <pbcast.NAKACK max_xmit_size="60000"
| use_mcast_xmit="false" gc_lag="0"
| retransmit_timeout="300,600,1200,2400,4800"
| discard_delivered_msgs="true"/>
| <UNICAST timeout="300,600,1200,2400,3600"/>
| <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
| max_bytes="400000"/>
| <pbcast.GMS print_local_addr="true" join_timeout="5000"
| join_retry_timeout="2000" shun="false"
| view_bundling="true" view_ack_collection_timeout="5000"/>
| <FRAG2 frag_size="60000"/>
| <pbcast.STREAMING_STATE_TRANSFER use_reading_thread="true"/>
| <!-- <pbcast.STATE_TRANSFER/> -->
| <pbcast.FLUSH timeout="0"/>
| </config>
| </attribute>
|
|
| <attribute name="FetchInMemoryState">true</attribute>
| <attribute name="StateRetrievalTimeout">15000</attribute>
| <attribute name="SyncReplTimeout">15000</attribute>
| <attribute name="LockAcquisitionTimeout">10000</attribute>
| <attribute name="UseRegionBasedMarshalling">true</attribute>
| </mbean>
| </server>
|
Spring conf (application-context.xml):
<?xml version="1.0" encoding="UTF-8"?>
| <beans xmlns="http://www.springframework.org/schema/beans"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xmlns:context="http://www.springframework.org/schema/context"
| xmlns:tx="http://www.springframework.org/schema/tx"
| xmlns:aop="http://www.springframework.org/schema/aop"
| xsi:schemaLocation="
| http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
| http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
| http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
| http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">
|
| <!--CONF GENERALE vvvvv-->
| <context:component-scan base-package="hellotrackworld"/>
| <context:annotation-config/>
| <!--CONF GENERALE ^^^^^-->
|
|
| <!--PARAMETRAGE JTA vvvvv-->
| <bean id="atomikosTransactionManager" class="com.atomikos.icatch.jta.UserTransactionManager" init-method="init" destroy-method="close">
| <property name="forceShutdown" value="true"/>
| </bean>
| <bean id="atomikosUserTransaction" class="com.atomikos.icatch.jta.UserTransactionImp">
| <property name="transactionTimeout" value="300"/>
| </bean>
|
| <bean id="jtaTransactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
| <property name="transactionManager" ref="atomikosTransactionManager" />
| <property name="userTransaction" ref="atomikosUserTransaction" />
| <property name="allowCustomIsolationLevels" value="true" />
| </bean>
|
| <tx:annotation-driven transaction-manager="jtaTransactionManager"/>
| <!--PARAMETRAGE JTA ^^^^^-->
|
| </beans>
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257591#4257591
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257591
15 years, 3 months
[Embedded JBoss Development] - Re: ShrinkWrap - Descriptors
by epbernard
"aslak" wrote : "epbernard" wrote :
| | BTW I dont' think specializes(Class<T extends Archive> clazz, Path basePath) should be here, what does it do to a real user, what's the use case?
| |
| | WarArchive war = ear.specializes(WebArchive.class, "my.war");
| | should raise an exception IMO as we do not specialize, we actually add a new archive inside an archive. An EAR contains a WAR, it is not a WAR.
| |
| We mostly create/add, but we have the Importer API as well, meaning you can import an existing war/jar/ear etc. In this case the API might not know what type of file is actually in there(here we could do some file extensions checks etc, but that's not always a fit. especially when it comes to descriptors).. So you want the Resource at Path X in the imported Archive 'specialized' as a WebArchive so that you can manipulate the classpath or web.xml.
|
|
I imagine that
ear.getModule("my.war").specializes(WebArchive.class) is a bit clearer, marginally more verbose and more consistent. WDYT?
anonymous wrote :
| "epbernard" wrote :
| | So if I sumamrize, a descriptor is a super interface of archive that describes a given configuration file like web.xml. Why separate it from the WebArchive interface exactly?
| |
| | Also remember that some configuration files can be at disfferent places and be multiple. For example in JPA, orm.xmls can be named as it pleases you and you can add many of them.
| |
| I Agree, I think most of the Descriptors(they are suppose to describe the content after all) are so tightly coupled with the Archive itself, that WebArchive implements WebArchiveDescriptor makes sense.
|
| The reason for having it as a separate Interface is to be able to have a Asset(file) implement the same, so that we can support adding descriptor files to different paths. ie:
|
| | WebArchive war = ..
| | war.addWebResource("my-web.xml", new WebArchiveDescriptorAsset());
| |
|
|
Well war.addWebResource returns WebArchive and that forces the user to break the fluent API to build the asset.
Trying idea. What if we merge somehow XArchive and ZAsset from the user PoV. The only difference would be the method that provides it. For example.
| archive.specializes(WebArchive.class)
| .displayName("Example")
| .addWebResource( "my-web.xml", WebArchive.class)
| .displayName("My Example")
| .addWebResource("my-web2.xml", WebArchive.class)
| // ...
| .addClass(User.class)
| .specializes(PersistenceArchive.class)
| .persistenceProvider(HibernatePersistence.class);
|
| //BTW displayName is better than setDisplayName for fluent APIs and tells
| //BTW2 addWebResource, couldn't it be addResource with a specialized logic when it's a web archive?
| the user that it's not a Java setter.
|
Better names still have to be found but the API flows more easily and the diff between an "asset" / file and an archive / zip is addXResource vs specializes.
Better names could be
specializes(WebDescriptor.class) => asArchive(WebDescriptor.class)
addWebResource => add(Web)Resource
anonymous wrote :
| Having the specializes(class, path) also helps out in your orm.xml example i guess..
|
| | JavaArchive jar = ..
| | PersistenceDescriptor desc = jar.specializes(PersistenceDescriptor.class, "my-orm.xml-path")
| |
|
But that's a resource in this case.
anonymous wrote :
| The name specializes might not be the correct wording in these cases. maybe something like "get as", "convert to" or "re map".
|
Exactly see above.
anonymous wrote :
| Another interesting 'issue' is how should we handle for instance the jboss-web.xml. In some cases it is all standalone, but in other it uses the same names as in web.xml.. descriptor pipeline ?
|
I don't quite understand this one but I am not familiar with jboss-web. WDYM by pipeline? If jboss-web extends the structure of web.xml, you can subclass WebDescriptor.class to JBossWebDescriptor.class
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257564#4257564
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257564
15 years, 3 months
[JBoss Transactions Development] - Re: Best way for ResourceManager to handle tx timeout
by jhalliday
XA_RBTIMEOUT is indeed preferable, but is handled by JBossTS in the same manner as XAER_NOTA. The distinction in spec terms is that XAER_NOTA is an error rather than an information code, which is not quite right in this case, since the timeout is actually working as intended. However, implementation considerations in the RM should probably trump such spec minutia.
Timeouts are useful where the RM uses locking and allowing those locks to be held too long causes throughput problems. If the RM is non-blocking then it becomes a question of resource allocation. If holding the tx open requires no resources and holds no locks, timeouts are irrelevant. Otherwise you need them for gc, or you need very robust connection handling so that you can do cleanup of unprepared tx on connection drop. TCP/IP being what it is, you won't always detect such drops unless you happen to have a heartbeat protocol between client and server.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257556#4257556
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257556
15 years, 3 months
[JBoss Transactions Development] - Best way for ResourceManager to handle tx timeout
by jmesnil
I am currently checking that HornetQ XAResource behave correctly wrt to transaction timeout. There is a whole discussion about it (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=144955) but I have some questions which are more general about how the TM and RM must cooperate.
If the RM accepts the transaction timeout set by the TM (XAResource.setTransactionTimeout() returns true) and rolls back a tx after the timeout, is it correct to return XA_ERRNOTA when the TM calls prepare() on the RM? Or MUST we return XA_RBTIMEOUT?
AIUI, returning XA_RBTIMEOUT gives the TM more contextual info but it will be handle the same way than XA_ERRNOTA. Is it the case for JBoss TS?
If we can return XAERR_NOTA, this means the RM can forget about the XID as soon as the tx timeout is hit. If we must return XA_RBTIMEOUT, it must keep the XID until the TM calls prepare().
Another question: Is there a real advantage for the RM to handle timeout?
The more I look at this issue for HornetQ, the less I am convinced we should handle tx timeout at all. It seems simpler to let the TM drive the whole thing.
The only issue I see with the RM not dealing with tx timeout is when the RM and TM runs in separate processes and the TM crashes.
wdyt?
jeff
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257548#4257548
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257548
15 years, 3 months
[Embedded JBoss Development] - Re: ShrinkWrap - Descriptors
by aslak
"epbernard" wrote :
| BTW I dont' think specializes(Class<T extends Archive> clazz, Path basePath) should be here, what does it do to a real user, what's the use case?
|
| WarArchive war = ear.specializes(WebArchive.class, "my.war");
| should raise an exception IMO as we do not specialize, we actually add a new archive inside an archive. An EAR contains a WAR, it is not a WAR.
|
We mostly create/add, but we have the Importer API as well, meaning you can import an existing war/jar/ear etc. In this case the API might not know what type of file is actually in there(here we could do some file extensions checks etc, but that's not always a fit. especially when it comes to descriptors).. So you want the Resource at Path X in the imported Archive 'specialized' as a WebArchive so that you can manipulate the classpath or web.xml.
"epbernard" wrote :
| So if I sumamrize, a descriptor is a super interface of archive that describes a given configuration file like web.xml. Why separate it from the WebArchive interface exactly?
|
| Also remember that some configuration files can be at disfferent places and be multiple. For example in JPA, orm.xmls can be named as it pleases you and you can add many of them.
|
I Agree, I think most of the Descriptors(they are suppose to describe the content after all) are so tightly coupled with the Archive itself, that WebArchive implements WebArchiveDescriptor makes sense.
The reason for having it as a separate Interface is to be able to have a Asset(file) implement the same, so that we can support adding descriptor files to different paths. ie:
| WebArchive war = ..
| war.addWebResource("my-web.xml", new WebArchiveDescriptorAsset());
|
Having the specializes(class, path) also helps out in your orm.xml example i guess..
| JavaArchive jar = ..
| PersistenceDescriptor desc = jar.specializes(PersistenceDescriptor.class, "my-orm.xml-path")
|
The name specializes might not be the correct wording in these cases. maybe something like "get as", "convert to" or "re map".
Another interesting 'issue' is how should we handle for instance the jboss-web.xml. In some cases it is all standalone, but in other it uses the same names as in web.xml.. descriptor pipeline ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257538#4257538
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257538
15 years, 3 months
[JBoss ESB Development] - Re: EBWS Security Support
by beve
Been thinking about this and one solution might be to:
1. In the ActionPipelineProcessor we check the actions attribute 'webservice'. If it is true we disable security in the action pipeline and don't perform any security processing. In this case we delegate security to the continer.
2. We add a 'securityDomain' attribute to the service element which would apply only when the 'webservice' attribute is true.
During deployment we use this 'securityDomain' value to set the securityDomain for the war. There is one issue here as mentioned above:
* If there is a http_provider configured it might already have specified a security domain which we will be overriding upon deployment, it might also be
the other way around but the effect is the same. This would throw an exception saying that the authentication domain has already been set.
We would need to document this fact and make sure users understand that there is a single web application for every jboss-esb.xml
Downsides:
1. It might not be obvious by reading the configuration that the same security domain is used by both the http provider and the service
2. Even though you can specify a 'securityDomain' attribute for every service in your jboss-esb.xml they all have to be the same
3. Security can be by-passed by using a ServiceInvoker to call the service directly.
Another option might be to have a global configuration for the security domain that applies to whole jboss-esb.xml. This would then be used for all http providers and all services. This would be a change from what is currently there where you can have different security domains (moduleNames) for different services in your jboss-esb.xml file.
Any thoughts on this?
Regards,
/Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257533#4257533
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257533
15 years, 3 months