Web services are probably the most common mechanism for distributed systems integration online at the moment.
In the Java world there are tools available to generate classes to act as remote proxies and interfaces.
Apache Axis and Axis2 provide a wsdl2java command line utility for generating these Java classes from a web service's WSDL file/URL.
What some people may not consider is that the implementation details of the stub which their client code will call, may not actually be safe to be called from multiple threads at the same time.
So, if you have a multithreaded application - such as a web app - where multiple threads could potentially be making calls on the web service via a shared instance of the generated stub then it is possible that some state that is set up as part of the processing of one thread could be changed by another thread.
It may not be apparent from looking at the generated code, but ultimately that code extends code buried within a jar that you do not have control over.
There are several approaches to avoiding the problem:
- create an instance of the stub for each call
- create and access stubs in a thread local way
- set up a pool of stubs, much the same way as database connections are often pooled.
I'm going to try out CommonsPoolTargetSource for the pooling approach.
Sunday 31 January 2010
Friday 29 January 2010
Web clustering gotcha
A recent web application that I worked on had some strange issues within a day of going live.
The configuration has 2 nodes serving web pages over http and https behind a load balancer.
Secure pages and logins are served over https, all other URLs are directed to be served over http.
Some users reported that they could successfully login, but the next link they clicked would lose the login.
It turned out that our load balancer configuration had separate stickiness tables for http and https, so there was some chance of a user being connected to node1 for http, and node2 for https. In some situations that would not matter, but the underlying application does not share session state across the cluster.
The configuration has 2 nodes serving web pages over http and https behind a load balancer.
Secure pages and logins are served over https, all other URLs are directed to be served over http.
Some users reported that they could successfully login, but the next link they clicked would lose the login.
It turned out that our load balancer configuration had separate stickiness tables for http and https, so there was some chance of a user being connected to node1 for http, and node2 for https. In some situations that would not matter, but the underlying application does not share session state across the cluster.
Monday 18 January 2010
Am I just being cynical?
A few days ago I noticed a blog post over at SpringSource that announced the intention to move dm Server across to the Eclipse Foundation.
I haven't been attending enough geek meetings lately to appreciate what is going on in the world of OSGi, or the politics of the VMware acquisition of SpringSource for that matter.
A cynical person might observe such an announcement and think, "that project has been identified as not being aligned with the core business, so it is being abandoned in the nicest possible way". Today I might be that cynical person.
The optimist in me is hoping that the Eclipse Foundation can make the system into something that takes off and provides as much benefit as the Eclipse IDE did when IBM released that.
Time will tell.
I haven't been attending enough geek meetings lately to appreciate what is going on in the world of OSGi, or the politics of the VMware acquisition of SpringSource for that matter.
A cynical person might observe such an announcement and think, "that project has been identified as not being aligned with the core business, so it is being abandoned in the nicest possible way". Today I might be that cynical person.
The optimist in me is hoping that the Eclipse Foundation can make the system into something that takes off and provides as much benefit as the Eclipse IDE did when IBM released that.
Time will tell.
Tuesday 5 January 2010
Geek meetups
Earlier this evening I attended the London eXtreme Tuesday Club for only my second time.
It was an interesting couple of hours of casual geeky conversation, including a live demo of some Erlang code for a handful of the group huddled around a netbook.
The general discussion around Scalar and Erlang reminded me of my first year of studying computer science at university, as our COSC122 course introduced a functional programming language (HUGS: Haskell User's Gofer System) with similar constructs to the currently trendy highly concurrent languages.
Hearing people talk about how Postgres is under-rated, and reminiscing about Perl made me feel a little old and nostalgic - in a good way. I like being able to nod knowingly when people mention the GIS capabilities, having compiled the PostGIS capabilities in from source for a couple of projects.
It was an interesting couple of hours of casual geeky conversation, including a live demo of some Erlang code for a handful of the group huddled around a netbook.
The general discussion around Scalar and Erlang reminded me of my first year of studying computer science at university, as our COSC122 course introduced a functional programming language (HUGS: Haskell User's Gofer System) with similar constructs to the currently trendy highly concurrent languages.
Hearing people talk about how Postgres is under-rated, and reminiscing about Perl made me feel a little old and nostalgic - in a good way. I like being able to nod knowingly when people mention the GIS capabilities, having compiled the PostGIS capabilities in from source for a couple of projects.
Monday 4 January 2010
A foreigner in a foreign land
If you've been developing software for long enough, you should have a reasonably good idea of what methodologies and technologies you can work well with.
I was fortunate enough to gain exposure to a range of different sized projects, using different approaches in the first decade of my career.
- Team sizes of 1 to 8;
- Timescales from a couple of days to 18 months;
- One-off throwaway scripts, enterprise applications that were maintained and in use for 5+ years;
- Solo missions, pair programming;
- Not worth testing, through to test-driven from unit to data access to GUI-driven automated suites;
When you've been with the company for that long you automatically know what sort of projects are going to come your way, and likewise your teammates know what you will be able to produce at the various stages, from design, to testing, development, delivery, and liaising with clients.
With a bigger company where nobody really knows all the ins and outs of the systems you're dealing with, and everyone seems to have a different view of the methodology it's difficult to explain the simple concept that "Garbage in" leads to "Garbage out".
I was fortunate enough to gain exposure to a range of different sized projects, using different approaches in the first decade of my career.
- Team sizes of 1 to 8;
- Timescales from a couple of days to 18 months;
- One-off throwaway scripts, enterprise applications that were maintained and in use for 5+ years;
- Solo missions, pair programming;
- Not worth testing, through to test-driven from unit to data access to GUI-driven automated suites;
When you've been with the company for that long you automatically know what sort of projects are going to come your way, and likewise your teammates know what you will be able to produce at the various stages, from design, to testing, development, delivery, and liaising with clients.
With a bigger company where nobody really knows all the ins and outs of the systems you're dealing with, and everyone seems to have a different view of the methodology it's difficult to explain the simple concept that "Garbage in" leads to "Garbage out".
Subscribe to:
Posts (Atom)