After long time and not to say with after giving up my thought of setting up nexus/artifactory/archiva I came back to same stuff recently around month back.
I restarted my exercise with nexus 1.2.1 and to my surprise with very little efforts I manage to get it up and running for Apache projects I care about which are CXF, Servicemix.
I also upgraded our team nexus repository manager from older version to 1.3.1 and happily using it now. It is lot more improved than I thought it would have been. In past I was very much annoyed when my pom files got corrupt for the artifacts that were present in more than one repositories I had configured but it appears to have been fixed now and also the web interface for configuration is very helpful.
Having said all this I did spent some time today in figuring out why the artifact present in remote repository won't download even though I had it configured it correctly. After a lot of head scratching and looking at the configuration multiple times discovered that there is a parameter on each repository you configure called Not Found Cache TTL which by default was set to 1440 Minute once I changed it to smaller amount like 2 minutes my build went ahead happily.
I am overall very happy with the new Nexus Repository Manager (surely much better experience than I had with proximity and old nexus version).
Wednesday, March 25, 2009
SOAP RPC/Encoded and style related articles
I recently looking for more information on RPC/encoded style came across two old but very good and simple articles so thought of bookmarking here via my Blog.
web-services-interoperability-between-j2ee-and-net-part-1
IBM-library-ws-whichwsdl
I have referenced the second one many times. It is very simple and handy to understand different between different SOAP message types.
web-services-interoperability-between-j2ee-and-net-part-1
IBM-library-ws-whichwsdl
I have referenced the second one many times. It is very simple and handy to understand different between different SOAP message types.
Thursday, August 21, 2008
Spring jmsTemplate threading issue
I recently encounter a problem while working on some Servicemix bug and it turned out that Servicemix jms provider is using spring-jms jmsTemplate and when there are multiple threads trying to do send receive (receiveSelected() to be precise) some of the messages are dropped.
While doing further investigation I found that multiple threads are using the same instance of spring-jms jmsTemplate that is created by the jms provider and this was causing some threading issue so thing to remember is to make the calls to jmsTemplate.receiveSelected() (atleast this one) synchronized.
UPDATE: I was too quick to diagnose the problem as jmsTemplate issue. With more drill down I was able to reproduce the problem with pure jmsTemplate and ActiveMQ combination and looks like a ActiveMQ issue than spring-jms. My friend Gary is getting it fixed in ActiveMQ currently.
While doing further investigation I found that multiple threads are using the same instance of spring-jms jmsTemplate that is created by the jms provider and this was causing some threading issue so thing to remember is to make the calls to jmsTemplate.receiveSelected() (atleast this one) synchronized.
UPDATE: I was too quick to diagnose the problem as jmsTemplate issue. With more drill down I was able to reproduce the problem with pure jmsTemplate and ActiveMQ combination and looks like a ActiveMQ issue than spring-jms. My friend Gary is getting it fixed in ActiveMQ currently.
Friday, August 15, 2008
Monday, August 11, 2008
Changes to Apache CXF JMS transport to allow jmsDestination name
Recently Apache CXF JMS transport is modified in order to allow use of jmsDestinationName and jmsReplyDestinationName. Till now CXF JMS only allowed using jndi destination names to lookup queue/destination and was not able to use jms destination names to create queues/topics.
Here is the diff of the schema change to specify the jmsDestinationName and jmsReplyDestinationName.
Example jms:address looks like this:
This will allow CXF consumer and services to use the real queue names (where JMS provider will allow the creation of the queues) as opposed to use jndi lookup.
Here is the diff of the schema change to specify the jmsDestinationName and jmsReplyDestinationName.
Example jms:address looks like this:
<jms:address jndiconnectionfactoryname="ConnectionFactory"
jmsdestinationname="dynamicQueues/routertest.SOAPService6Q.text"
jmsreplydestinationname="dynamicQueues/SoapService6.reply.queue">
<jms:jmsnamingproperty name="java.naming.factory.initial"
value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/>
<jms:jmsnamingproperty name="java.naming.provider.url"
value="tcp://localhost:61500"/>
</jms:address>
This will allow CXF consumer and services to use the real queue names (where JMS provider will allow the creation of the queues) as opposed to use jndi lookup.
handy tip on how to increase jetty HttpClient threadpool size in ServiceMix 3.2.2
I was recently working on some jetty related issue in Servicemix 3.2 and got Servicemix people to update servicemix-http component to have configurable jetty httpClient thread pool size. Before I forget it I wanted to make a note of it so adding this entry.
In Servicemix 3.2.2 and onwards jetty HttpClient threadpool can be configured using following entry in component.properties file.
servicemix-http.jettyClientThreadPoolSize=33
Also, you can configure Servicemix to use Jetty httpClient per httpProvider (by default a single client is shared among all httpProviderEndpoints) by adding
servicemix-http.jettyHttpClientPerProvider=true
Also from ServiceMix 3.2.2 onwards Jetty HttpClient uses nio channel selector implementation of jetty. (previously it was using socket connector which was blocking I/O and was causing thread locking in thread pool in some stress conditions)
In Servicemix 3.2.2 and onwards jetty HttpClient threadpool can be configured using following entry in component.properties file.
servicemix-http.jettyClientThreadPoolSize=33
Also, you can configure Servicemix to use Jetty httpClient per httpProvider (by default a single client is shared among all httpProviderEndpoints) by adding
servicemix-http.jettyHttpClientPerProvider=true
Also from ServiceMix 3.2.2 onwards Jetty HttpClient uses nio channel selector implementation of jetty. (previously it was using socket connector which was blocking I/O and was causing thread locking in thread pool in some stress conditions)
Friday, August 1, 2008
Subscribe to:
Posts (Atom)