You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Hannes Erven <ha...@erven.at> on 2006/03/03 18:00:20 UTC
Speed improvements for ATCoordinator
Hi Dasarath,
hi folks,
attached are two patches of today's coding session with Georg.
First, the promised patch against ATCoordinator to speed up waiting
delays when preparing and terminating 2PC transactions. We managed to
get the total transaction time from ~12 seconds down to about 1 second.
In the process, we removed the RESPONSE_DELAY_MILLIS parameter as we
felt it is not needed anymore.
The second patch is against ParticipantImpl and adds exceptions that are
thrown when addressing headers are missing. This helps when debugging
clients that have an incomplete axis client configuration ;-)
BTW, can we use Java 1.5 (generics, @Override, ...) or do we rather
stick to 1.3/1.4?
BTW, did you look at our recent patch which adds a second configuration
option to specify the kandula services context URL to use?
Best regards & have a nice weekday,
-hannes
Re: Speed improvements for ATCoordinator
Posted by Hannes Erven <ha...@erven.at>.
Hi Dasarath,
>>BTW, did you look at our recent patch which adds a second configuration
>>option to specify the kandula services context URL to use?
>
> this patch I'm still not sure what you'll are shooting for-- what I feel is that
> the requirement is met by the current code. may be if you could put it in
> another way/example may be that will help.
With the existing code base an application can pass the desired
activation service EPR to begin().
We felt it was more convenient to allow a default activation service EPR
to be specified in the configuration file; applications may still use
other activation services by passing an EPR to begin().
Well, thats it ;-)
If you wonder why one would want to use a remote activation service:
this allows initiating applications to be "firewalled" from the actual
participants; only the coordinator specified in the kandula.properties
must be able to send messages to the initiator.
Have a nice week*end* and good luck for your tests ;-),
-hannes
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Speed improvements for ATCoordinator
Posted by Hannes Erven <ha...@erven.at>.
Hi Dasarath,
>>BTW, did you look at our recent patch which adds a second configuration
>>option to specify the kandula services context URL to use?
>
> this patch I'm still not sure what you'll are shooting for-- what I feel is that
> the requirement is met by the current code. may be if you could put it in
> another way/example may be that will help.
With the existing code base an application can pass the desired
activation service EPR to begin().
We felt it was more convenient to allow a default activation service EPR
to be specified in the configuration file; applications may still use
other activation services by passing an EPR to begin().
Well, thats it ;-)
If you wonder why one would want to use a remote activation service:
this allows initiating applications to be "firewalled" from the actual
participants; only the coordinator specified in the kandula.properties
must be able to send messages to the initiator.
Have a nice week*end* and good luck for your tests ;-),
-hannes
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Speed improvements for ATCoordinator
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Quoting Hannes Erven <ha...@erven.at>:
> attached are two patches of today's coding session with Georg.
>
> First, the promised patch against ATCoordinator to speed up waiting
> delays when preparing and terminating 2PC transactions. We managed to
> get the total transaction time from ~12 seconds down to about 1 second.
> In the process, we removed the RESPONSE_DELAY_MILLIS parameter as we
> felt it is not needed anymore.
>
>
> The second patch is against ParticipantImpl and adds exceptions that are
> thrown when addressing headers are missing. This helps when debugging
> clients that have an incomplete axis client configuration ;-)
thanks ppl. I will surely look at this soon and write a detail reply. I'm a bit
tied up this week.
>
>
> BTW, can we use Java 1.5 (generics, @Override, ...) or do we rather
> stick to 1.3/1.4?
stick to 1.4.2 for now. this depends on what axis uses. we cannot switch unless
they also follow.
> BTW, did you look at our recent patch which adds a second configuration
> option to specify the kandula services context URL to use?
this patch I'm still not sure what you'll are shooting for-- what I feel is that
the requirement is met by the current code. may be if you could put it in
another way/example may be that will help.
thanks again.
--dasarath
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Speed improvements for ATCoordinator
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Quoting Hannes Erven <ha...@erven.at>:
> attached are two patches of today's coding session with Georg.
>
> First, the promised patch against ATCoordinator to speed up waiting
> delays when preparing and terminating 2PC transactions. We managed to
> get the total transaction time from ~12 seconds down to about 1 second.
> In the process, we removed the RESPONSE_DELAY_MILLIS parameter as we
> felt it is not needed anymore.
>
>
> The second patch is against ParticipantImpl and adds exceptions that are
> thrown when addressing headers are missing. This helps when debugging
> clients that have an incomplete axis client configuration ;-)
thanks ppl. I will surely look at this soon and write a detail reply. I'm a bit
tied up this week.
>
>
> BTW, can we use Java 1.5 (generics, @Override, ...) or do we rather
> stick to 1.3/1.4?
stick to 1.4.2 for now. this depends on what axis uses. we cannot switch unless
they also follow.
> BTW, did you look at our recent patch which adds a second configuration
> option to specify the kandula services context URL to use?
this patch I'm still not sure what you'll are shooting for-- what I feel is that
the requirement is met by the current code. may be if you could put it in
another way/example may be that will help.
thanks again.
--dasarath
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re： Speed improvements for ATCoordinator
Posted by Jack Wang <pi...@yahoo.com>.
--- Hannes Erven <ha...@erven.at>写道:
> attached are two patches of today's coding session with Georg.
>
> First, the promised patch against ATCoordinator to speed up waiting
> delays when preparing and terminating 2PC transactions. We managed to
> get the total transaction time from ~12 seconds down to about 1 second.
> In the process, we removed the RESPONSE_DELAY_MILLIS parameter as we
> felt it is not needed anymore.
It works faster indeed, thanks.
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re： Speed improvements for ATCoordinator
Posted by Jack Wang <pi...@yahoo.com>.
--- Hannes Erven <ha...@erven.at>写道:
> attached are two patches of today's coding session with Georg.
>
> First, the promised patch against ATCoordinator to speed up waiting
> delays when preparing and terminating 2PC transactions. We managed to
> get the total transaction time from ~12 seconds down to about 1 second.
> In the process, we removed the RESPONSE_DELAY_MILLIS parameter as we
> felt it is not needed anymore.
It works faster indeed, thanks.
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org