You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Samisa Abeysinghe <sa...@gmail.com> on 2005/01/25 08:59:45 UTC

ChannelFactory::LoadChannelLibrary is called for each method call on Stub

Hi,
    It looks to me that the above mentioned method is called for each
method invocation.
    This is because we have 
m_pTransport->setTransportProperty( CHANNEL_HTTP_DLL_NAME,
pcChannelHTTPLibraryPath);

inside Call::openConnection() and this is called by Call::initialize()
which is always called when a method is invoked.

    The code works OK, but the problem is in case of performance.
1. A Channel object is created for every method invocation
2. Because of 1 above, we always have to create a new connection
3. 2 above violates Connection-keep-alive in HTTP/1.1

In axis2 transport, we had the featurer, where the connection to
service is re-established iff the URL changes, thus re-using the same
connection for subsequent invocations in case of HTTP/1.1

Because of the channel loading mechanism, it is a but though to do the
same in case of axis3. But I think if we conditionnaly invoke
m_pTransport->setTransportProperty( CHANNEL_HTTP_DLL_NAME,
pcChannelHTTPLibraryPath); if and only if pcChannelHTTPLibraryPath has
changed, then we could increase the efficancy.
Using something like:
if( !strcmp(pcChannelHTTPLibraryPath, pcOldChannelHTTPLibraryPath)
{
    m_pTransport->setTransportProperty( CHANNEL_HTTP_DLL_NAME,
pcChannelHTTPLibraryPath);
}

If we change this, the connection related stuff will work as axis2 as
we used the same code here in axis3.
I did not change any code in CVS because I am not sure if the above
would have any side effects or any other related concerns.

Thoughts please.

Thanks,
Samisa...

Re: ChannelFactory::LoadChannelLibrary is called for each method call on Stub

Posted by Samisa Abeysinghe <sa...@gmail.com>.
With the latest changes done to axis3 transport by Fred, this too seem
to be fixed as well, not at the Call class level but at Transport
level (most probably in ChannelFactory class)

I think it is a better solution.

Thanks,
Samisa...


On Tue, 25 Jan 2005 09:54:36 +0000, John Hawkins <HA...@uk.ibm.com> wrote:
>  
> Sounds like a good idea +1 
> 
>  
>  
> John Hawkins
>  
>  
>  
>  
>  
>  Samisa Abeysinghe <sa...@gmail.com> 
> 
> 25/01/2005 07:59 
>  
> Please respond to
>  "Apache AXIS C Developers List" 
>  
>  
> To Apache AXIS C Developers List <ax...@ws.apache.org> 
>  
> cc 
>  
> Subject ChannelFactory::LoadChannelLibrary is called for each method call on
> Stub 
>  
>  
>  
>  
>  
> Hi,
>     It looks to me that the above mentioned method is called for each
>  method invocation.
>     This is because we have 
>  m_pTransport->setTransportProperty( CHANNEL_HTTP_DLL_NAME,
>  pcChannelHTTPLibraryPath);
>  
>  inside Call::openConnection() and this is called by Call::initialize()
>  which is always called when a method is invoked.
>  
>     The code works OK, but the problem is in case of performance.
>  1. A Channel object is created for every method invocation
>  2. Because of 1 above, we always have to create a new connection
>  3. 2 above violates Connection-keep-alive in HTTP/1.1
>  
>  In axis2 transport, we had the featurer, where the connection to
>  service is re-established iff the URL changes, thus re-using the same
>  connection for subsequent invocations in case of HTTP/1.1
>  
>  Because of the channel loading mechanism, it is a but though to do the
>  same in case of axis3. But I think if we conditionnaly invoke
>  m_pTransport->setTransportProperty( CHANNEL_HTTP_DLL_NAME,
>  pcChannelHTTPLibraryPath); if and only if pcChannelHTTPLibraryPath has
>  changed, then we could increase the efficancy.
>  Using something like:
>  if( !strcmp(pcChannelHTTPLibraryPath, pcOldChannelHTTPLibraryPath)
>  {
>     m_pTransport->setTransportProperty( CHANNEL_HTTP_DLL_NAME,
>  pcChannelHTTPLibraryPath);
>  }
>  
>  If we change this, the connection related stuff will work as axis2 as
>  we used the same code here in axis3.
>  I did not change any code in CVS because I am not sure if the above
>  would have any side effects or any other related concerns.
>  
>  Thoughts please.
>  
>  Thanks,
>  Samisa...
>  
>

Re: ChannelFactory::LoadChannelLibrary is called for each method call on Stub

Posted by John Hawkins <HA...@uk.ibm.com>.
Sounds like a good idea +1



John Hawkins





Samisa Abeysinghe <sa...@gmail.com> 
25/01/2005 07:59
Please respond to
"Apache AXIS C Developers List"


To
Apache AXIS C Developers List <ax...@ws.apache.org>
cc

Subject
ChannelFactory::LoadChannelLibrary is called for each method call on Stub






Hi,
    It looks to me that the above mentioned method is called for each
method invocation.
    This is because we have 
m_pTransport->setTransportProperty( CHANNEL_HTTP_DLL_NAME,
pcChannelHTTPLibraryPath);

inside Call::openConnection() and this is called by Call::initialize()
which is always called when a method is invoked.

    The code works OK, but the problem is in case of performance.
1. A Channel object is created for every method invocation
2. Because of 1 above, we always have to create a new connection
3. 2 above violates Connection-keep-alive in HTTP/1.1

In axis2 transport, we had the featurer, where the connection to
service is re-established iff the URL changes, thus re-using the same
connection for subsequent invocations in case of HTTP/1.1

Because of the channel loading mechanism, it is a but though to do the
same in case of axis3. But I think if we conditionnaly invoke
m_pTransport->setTransportProperty( CHANNEL_HTTP_DLL_NAME,
pcChannelHTTPLibraryPath); if and only if pcChannelHTTPLibraryPath has
changed, then we could increase the efficancy.
Using something like:
if( !strcmp(pcChannelHTTPLibraryPath, pcOldChannelHTTPLibraryPath)
{
    m_pTransport->setTransportProperty( CHANNEL_HTTP_DLL_NAME,
pcChannelHTTPLibraryPath);
}

If we change this, the connection related stuff will work as axis2 as
we used the same code here in axis3.
I did not change any code in CVS because I am not sure if the above
would have any side effects or any other related concerns.

Thoughts please.

Thanks,
Samisa...