You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Alp Timurhan Çevik <at...@gmail.com> on 2008/10/22 15:04:33 UTC
Huge wsdl (HL7 v3) performance problem (a.k.a how jaxb is ruining my life)
Hello,
I need to connect to a server that has an HL7 v3 based wsdl document which
has tens of thousands of different types. I have a server application which
listens for some events and sends data to these web services.
I am currently having performance problem at startup. It takes 5-10 minutes
for the service to complete jaxb initialization (I guess). After the first
call, things run smoothly, responding at max 10 seconds.
In order to solve the problem, I have began to send a dummy message at the
startup, which seemed like solving my performance problem at startup, but
later on I found out that after some inactivity time, the first message
problem just resurrects. I thought as I do have a lot of classdefinitions
from these wsdls, the noclassgc jvm parameter could solve my problem, but
alas it did not. Actually it is not an easy problem to test, also, because I
have to wait for the timeout.
I am thinking of sending the dummy messages regularly, but the server
application I run is also running some simple web services which sends data
to hl7 v3 (the huge ones) web services and replies to the users according to
the response from hl7 v3s.
I have also tried sxj but still startup performance is miserable.
Any suggestions ?
Best regards,
Alp Timurhan Çevik
Re: Huge wsdl (HL7 v3) performance problem (a.k.a how jaxb is ruining my life)
Posted by Alp Timurhan Çevik <at...@gmail.com>.
Adrian,
I guess you were right about keeping a reference to port object, which
references the jaxbcontext and prevents it from being garbage collected. One
of the tricks is to keep a port object to the server application which keeps
on running, so that no gc magic will reach the precious context.
Still trying if this is the issue, will have to wait for some timeout/gc
triggering, but I think this is the solution.
Thanks a lot for your help.
On Wed, Oct 22, 2008 at 5:30 PM, Alp Timurhan Çevik <at...@gmail.com>wrote:
> I have been in debugging, and yes, I guess the problem is jaxb context
> initialization. It takes a lot of time. Now the question is,
>
> How do I get the garbage collection to exclude collecting jaxbcontext?
>
> P.S. I was right at the beginning after all. This jaxb guy was the one
> ruining my life, along with gc. So, yes jaxb, the title remains the same and
> i will kick jaxb around if I see him again.
>
>
> On Wed, Oct 22, 2008 at 5:01 PM, Alp Timurhan Çevik <at...@gmail.com>wrote:
>
>> Could be due to something related to
>> org.apache.cxf.jaxws.ServiceImpl.getPort()
>>
>>
>> On Wed, Oct 22, 2008 at 4:53 PM, Alp Timurhan Çevik <at...@gmail.com>wrote:
>>
>>>
>>> The message is somethink between 20K-50K, the actual call does not occur
>>> on getting the port using port = service.getMCCIAR000001TRPort() , occurs on
>>> port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message)
>>> conversionResult). So the transport delay /lag is not present yet (I guess).
>>> I am also using threading, and by the way, the performance problem is not
>>> present after the first call (at least during some time, in order to make
>>> things complicated). So I do not think the issue is due to creating several
>>> instances.
>>>
>>> Could it be something related to wsdl parsing ? I do not know. All I can
>>> think of is garbage collection of classes after some amount of time, but
>>> still I am nowhere.
>>>
>>>
>>>
>>> On Wed, Oct 22, 2008 at 4:40 PM, Adrian Corcoran <
>>> adrian.corcoran@gmail.com> wrote:
>>>
>>>> This is perhaps got to do with the way that you are consuming the
>>>> services.
>>>>
>>>> port = service.getMCCIAR000001TRPort()
>>>>
>>>> You probably only need to create this once and you should the be able to
>>>> re-use it (be careful of you threading model thou).
>>>>
>>>> The call port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message), is
>>>> the
>>>> time being lost over the wire, or in marshalling the message, what type
>>>> of
>>>> size is the message?
>>>>
>>>> On Wed, Oct 22, 2008 at 2:31 PM, Alp Timurhan Çevik <atcevik@gmail.com
>>>> >wrote:
>>>>
>>>> > Adrian,
>>>> >
>>>> > I am not very familiar with jaxb, so I cannot give a yes or no answer,
>>>> but
>>>> > let me try to explain.
>>>> >
>>>> > While debugging, I get to the part where jaxb generated objects is
>>>> > populated
>>>> > fastly, but the part where the actual message sending occurs, the
>>>> > performance is miserable at first call.
>>>> >
>>>> > I am not using Spring. The initialization is like
>>>> >
>>>> >
>>>> >
>>>> org.apache.cxf.common.logging.LogUtils.setLoggerClass(Log4jLogger.class);
>>>> > SaglikNetAdapterWebService serviceImpl = new XWebService();
>>>> > JaxWsServerFactoryBean svrFactory = new
>>>> JaxWsServerFactoryBean();
>>>> > svrFactory.setServiceBean(serviceImpl);
>>>> > svrFactory.setServiceClass(XWebServiceInterface.class);
>>>> >
>>>> >
>>>> >
>>>> svrFactory.setAddress(PlainWebServiceConstants.getString("ServerService.ServiceRealAdress"));
>>>> >
>>>> >
>>>> >
>>>> svrFactory.setPublishedEndpointUrl(PlainWebServiceConstants.getString("ServerService.WsdlDeclaredAdress"));
>>>> > svrFactory.getInInterceptors().add(new
>>>> > PlainMessagePersistenceLoggerInterceptor());
>>>> > enableWsdlValidation(svrFactory);
>>>> > Server server = svrFactory.create();
>>>> >
>>>> > Calling the service is
>>>> >
>>>> > MCCIAR000001TRPortType port;
>>>> > service.setHandlerResolver(new
>>>> HL7InsertMessageHandlerResolver(uuid,
>>>> > ServiceClientDbUtils.getSessionFactory(),
>>>> > transaction));
>>>> > port = service.getMCCIAR000001TRPort();
>>>> > port = ServiceClientUtils.changeDestinationAdress(port,
>>>> > transaction);
>>>> > port =
>>>> > ServiceClientSecurityHeaderUtils.createSecurityHeader(userInfo,
>>>> paketTuru,
>>>> > uuid, port);
>>>> >
>>>> > which is the first part where it takes a lot to execute. Especially
>>>> > port = service.getMCCIAR000001TRPort();
>>>> >
>>>> >
>>>> > ...
>>>> > ...
>>>> > ...
>>>> > ...
>>>> > return port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message)
>>>> > conversionResult);
>>>> >
>>>> > part also takes time.
>>>> >
>>>> > Also, wsdl validation occurs in no time, it even is very fast on first
>>>> > call.
>>>> >
>>>> >
>>>> > P.S. I recognized that I really do not know if the problem is due to
>>>> Jaxb,
>>>> > so I apologize from jaxb because of the subject. I should change it to
>>>> how
>>>> > something I do not even know ruins my life.
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Oct 22, 2008 at 4:15 PM, Adrian Corcoran
>>>> > <ad...@gmail.com>wrote:
>>>> >
>>>> > > Is it possible to initialize the jaxb context using spring and wire
>>>> it
>>>> > into
>>>> > > your service?
>>>> > >
>>>> > > I presume that that its the jaxb context initialization that is
>>>> taking
>>>> > all
>>>> > > the time?
>>>> > >
>>>> > > On Wed, Oct 22, 2008 at 2:04 PM, Alp Timurhan Çevik <
>>>> atcevik@gmail.com
>>>> > > >wrote:
>>>> > >
>>>> > > > Hello,
>>>> > > >
>>>> > > > I need to connect to a server that has an HL7 v3 based wsdl
>>>> document
>>>> > > which
>>>> > > > has tens of thousands of different types. I have a server
>>>> application
>>>> > > which
>>>> > > > listens for some events and sends data to these web services.
>>>> > > >
>>>> > > > I am currently having performance problem at startup. It takes
>>>> 5-10
>>>> > > minutes
>>>> > > > for the service to complete jaxb initialization (I guess). After
>>>> the
>>>> > > first
>>>> > > > call, things run smoothly, responding at max 10 seconds.
>>>> > > >
>>>> > > > In order to solve the problem, I have began to send a dummy
>>>> message at
>>>> > > the
>>>> > > > startup, which seemed like solving my performance problem at
>>>> startup,
>>>> > but
>>>> > > > later on I found out that after some inactivity time, the first
>>>> message
>>>> > > > problem just resurrects. I thought as I do have a lot of
>>>> > classdefinitions
>>>> > > > from these wsdls, the noclassgc jvm parameter could solve my
>>>> problem,
>>>> > but
>>>> > > > alas it did not. Actually it is not an easy problem to test, also,
>>>> > > because
>>>> > > > I
>>>> > > > have to wait for the timeout.
>>>> > > >
>>>> > > > I am thinking of sending the dummy messages regularly, but the
>>>> server
>>>> > > > application I run is also running some simple web services which
>>>> sends
>>>> > > data
>>>> > > > to hl7 v3 (the huge ones) web services and replies to the users
>>>> > according
>>>> > > > to
>>>> > > > the response from hl7 v3s.
>>>> > > >
>>>> > > > I have also tried sxj but still startup performance is miserable.
>>>> > > >
>>>> > > > Any suggestions ?
>>>> > > >
>>>> > > > Best regards,
>>>> > > > Alp Timurhan Çevik
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
>>>
>>
>
Re: Huge wsdl (HL7 v3) performance problem (a.k.a how jaxb is ruining my life)
Posted by Alp Timurhan Çevik <at...@gmail.com>.
I have been in debugging, and yes, I guess the problem is jaxb context
initialization. It takes a lot of time. Now the question is,
How do I get the garbage collection to exclude collecting jaxbcontext?
P.S. I was right at the beginning after all. This jaxb guy was the one
ruining my life, along with gc. So, yes jaxb, the title remains the same and
i will kick jaxb around if I see him again.
On Wed, Oct 22, 2008 at 5:01 PM, Alp Timurhan Çevik <at...@gmail.com>wrote:
> Could be due to something related to
> org.apache.cxf.jaxws.ServiceImpl.getPort()
>
>
> On Wed, Oct 22, 2008 at 4:53 PM, Alp Timurhan Çevik <at...@gmail.com>wrote:
>
>>
>> The message is somethink between 20K-50K, the actual call does not occur
>> on getting the port using port = service.getMCCIAR000001TRPort() , occurs on
>> port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message)
>> conversionResult). So the transport delay /lag is not present yet (I guess).
>> I am also using threading, and by the way, the performance problem is not
>> present after the first call (at least during some time, in order to make
>> things complicated). So I do not think the issue is due to creating several
>> instances.
>>
>> Could it be something related to wsdl parsing ? I do not know. All I can
>> think of is garbage collection of classes after some amount of time, but
>> still I am nowhere.
>>
>>
>>
>> On Wed, Oct 22, 2008 at 4:40 PM, Adrian Corcoran <
>> adrian.corcoran@gmail.com> wrote:
>>
>>> This is perhaps got to do with the way that you are consuming the
>>> services.
>>>
>>> port = service.getMCCIAR000001TRPort()
>>>
>>> You probably only need to create this once and you should the be able to
>>> re-use it (be careful of you threading model thou).
>>>
>>> The call port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message), is
>>> the
>>> time being lost over the wire, or in marshalling the message, what type
>>> of
>>> size is the message?
>>>
>>> On Wed, Oct 22, 2008 at 2:31 PM, Alp Timurhan Çevik <atcevik@gmail.com
>>> >wrote:
>>>
>>> > Adrian,
>>> >
>>> > I am not very familiar with jaxb, so I cannot give a yes or no answer,
>>> but
>>> > let me try to explain.
>>> >
>>> > While debugging, I get to the part where jaxb generated objects is
>>> > populated
>>> > fastly, but the part where the actual message sending occurs, the
>>> > performance is miserable at first call.
>>> >
>>> > I am not using Spring. The initialization is like
>>> >
>>> >
>>> >
>>> org.apache.cxf.common.logging.LogUtils.setLoggerClass(Log4jLogger.class);
>>> > SaglikNetAdapterWebService serviceImpl = new XWebService();
>>> > JaxWsServerFactoryBean svrFactory = new
>>> JaxWsServerFactoryBean();
>>> > svrFactory.setServiceBean(serviceImpl);
>>> > svrFactory.setServiceClass(XWebServiceInterface.class);
>>> >
>>> >
>>> >
>>> svrFactory.setAddress(PlainWebServiceConstants.getString("ServerService.ServiceRealAdress"));
>>> >
>>> >
>>> >
>>> svrFactory.setPublishedEndpointUrl(PlainWebServiceConstants.getString("ServerService.WsdlDeclaredAdress"));
>>> > svrFactory.getInInterceptors().add(new
>>> > PlainMessagePersistenceLoggerInterceptor());
>>> > enableWsdlValidation(svrFactory);
>>> > Server server = svrFactory.create();
>>> >
>>> > Calling the service is
>>> >
>>> > MCCIAR000001TRPortType port;
>>> > service.setHandlerResolver(new
>>> HL7InsertMessageHandlerResolver(uuid,
>>> > ServiceClientDbUtils.getSessionFactory(),
>>> > transaction));
>>> > port = service.getMCCIAR000001TRPort();
>>> > port = ServiceClientUtils.changeDestinationAdress(port,
>>> > transaction);
>>> > port =
>>> > ServiceClientSecurityHeaderUtils.createSecurityHeader(userInfo,
>>> paketTuru,
>>> > uuid, port);
>>> >
>>> > which is the first part where it takes a lot to execute. Especially
>>> > port = service.getMCCIAR000001TRPort();
>>> >
>>> >
>>> > ...
>>> > ...
>>> > ...
>>> > ...
>>> > return port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message)
>>> > conversionResult);
>>> >
>>> > part also takes time.
>>> >
>>> > Also, wsdl validation occurs in no time, it even is very fast on first
>>> > call.
>>> >
>>> >
>>> > P.S. I recognized that I really do not know if the problem is due to
>>> Jaxb,
>>> > so I apologize from jaxb because of the subject. I should change it to
>>> how
>>> > something I do not even know ruins my life.
>>> >
>>> >
>>> >
>>> > On Wed, Oct 22, 2008 at 4:15 PM, Adrian Corcoran
>>> > <ad...@gmail.com>wrote:
>>> >
>>> > > Is it possible to initialize the jaxb context using spring and wire
>>> it
>>> > into
>>> > > your service?
>>> > >
>>> > > I presume that that its the jaxb context initialization that is
>>> taking
>>> > all
>>> > > the time?
>>> > >
>>> > > On Wed, Oct 22, 2008 at 2:04 PM, Alp Timurhan Çevik <
>>> atcevik@gmail.com
>>> > > >wrote:
>>> > >
>>> > > > Hello,
>>> > > >
>>> > > > I need to connect to a server that has an HL7 v3 based wsdl
>>> document
>>> > > which
>>> > > > has tens of thousands of different types. I have a server
>>> application
>>> > > which
>>> > > > listens for some events and sends data to these web services.
>>> > > >
>>> > > > I am currently having performance problem at startup. It takes 5-10
>>> > > minutes
>>> > > > for the service to complete jaxb initialization (I guess). After
>>> the
>>> > > first
>>> > > > call, things run smoothly, responding at max 10 seconds.
>>> > > >
>>> > > > In order to solve the problem, I have began to send a dummy message
>>> at
>>> > > the
>>> > > > startup, which seemed like solving my performance problem at
>>> startup,
>>> > but
>>> > > > later on I found out that after some inactivity time, the first
>>> message
>>> > > > problem just resurrects. I thought as I do have a lot of
>>> > classdefinitions
>>> > > > from these wsdls, the noclassgc jvm parameter could solve my
>>> problem,
>>> > but
>>> > > > alas it did not. Actually it is not an easy problem to test, also,
>>> > > because
>>> > > > I
>>> > > > have to wait for the timeout.
>>> > > >
>>> > > > I am thinking of sending the dummy messages regularly, but the
>>> server
>>> > > > application I run is also running some simple web services which
>>> sends
>>> > > data
>>> > > > to hl7 v3 (the huge ones) web services and replies to the users
>>> > according
>>> > > > to
>>> > > > the response from hl7 v3s.
>>> > > >
>>> > > > I have also tried sxj but still startup performance is miserable.
>>> > > >
>>> > > > Any suggestions ?
>>> > > >
>>> > > > Best regards,
>>> > > > Alp Timurhan Çevik
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: Huge wsdl (HL7 v3) performance problem (a.k.a how jaxb is ruining my life)
Posted by Alp Timurhan Çevik <at...@gmail.com>.
Could be due to something related to
org.apache.cxf.jaxws.ServiceImpl.getPort()
On Wed, Oct 22, 2008 at 4:53 PM, Alp Timurhan Çevik <at...@gmail.com>wrote:
>
> The message is somethink between 20K-50K, the actual call does not occur on
> getting the port using port = service.getMCCIAR000001TRPort() , occurs on
> port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message)
> conversionResult). So the transport delay /lag is not present yet (I guess).
> I am also using threading, and by the way, the performance problem is not
> present after the first call (at least during some time, in order to make
> things complicated). So I do not think the issue is due to creating several
> instances.
>
> Could it be something related to wsdl parsing ? I do not know. All I can
> think of is garbage collection of classes after some amount of time, but
> still I am nowhere.
>
>
>
> On Wed, Oct 22, 2008 at 4:40 PM, Adrian Corcoran <
> adrian.corcoran@gmail.com> wrote:
>
>> This is perhaps got to do with the way that you are consuming the
>> services.
>>
>> port = service.getMCCIAR000001TRPort()
>>
>> You probably only need to create this once and you should the be able to
>> re-use it (be careful of you threading model thou).
>>
>> The call port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message), is
>> the
>> time being lost over the wire, or in marshalling the message, what type of
>> size is the message?
>>
>> On Wed, Oct 22, 2008 at 2:31 PM, Alp Timurhan Çevik <atcevik@gmail.com
>> >wrote:
>>
>> > Adrian,
>> >
>> > I am not very familiar with jaxb, so I cannot give a yes or no answer,
>> but
>> > let me try to explain.
>> >
>> > While debugging, I get to the part where jaxb generated objects is
>> > populated
>> > fastly, but the part where the actual message sending occurs, the
>> > performance is miserable at first call.
>> >
>> > I am not using Spring. The initialization is like
>> >
>> >
>> >
>> org.apache.cxf.common.logging.LogUtils.setLoggerClass(Log4jLogger.class);
>> > SaglikNetAdapterWebService serviceImpl = new XWebService();
>> > JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
>> > svrFactory.setServiceBean(serviceImpl);
>> > svrFactory.setServiceClass(XWebServiceInterface.class);
>> >
>> >
>> >
>> svrFactory.setAddress(PlainWebServiceConstants.getString("ServerService.ServiceRealAdress"));
>> >
>> >
>> >
>> svrFactory.setPublishedEndpointUrl(PlainWebServiceConstants.getString("ServerService.WsdlDeclaredAdress"));
>> > svrFactory.getInInterceptors().add(new
>> > PlainMessagePersistenceLoggerInterceptor());
>> > enableWsdlValidation(svrFactory);
>> > Server server = svrFactory.create();
>> >
>> > Calling the service is
>> >
>> > MCCIAR000001TRPortType port;
>> > service.setHandlerResolver(new
>> HL7InsertMessageHandlerResolver(uuid,
>> > ServiceClientDbUtils.getSessionFactory(),
>> > transaction));
>> > port = service.getMCCIAR000001TRPort();
>> > port = ServiceClientUtils.changeDestinationAdress(port,
>> > transaction);
>> > port =
>> > ServiceClientSecurityHeaderUtils.createSecurityHeader(userInfo,
>> paketTuru,
>> > uuid, port);
>> >
>> > which is the first part where it takes a lot to execute. Especially
>> > port = service.getMCCIAR000001TRPort();
>> >
>> >
>> > ...
>> > ...
>> > ...
>> > ...
>> > return port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message)
>> > conversionResult);
>> >
>> > part also takes time.
>> >
>> > Also, wsdl validation occurs in no time, it even is very fast on first
>> > call.
>> >
>> >
>> > P.S. I recognized that I really do not know if the problem is due to
>> Jaxb,
>> > so I apologize from jaxb because of the subject. I should change it to
>> how
>> > something I do not even know ruins my life.
>> >
>> >
>> >
>> > On Wed, Oct 22, 2008 at 4:15 PM, Adrian Corcoran
>> > <ad...@gmail.com>wrote:
>> >
>> > > Is it possible to initialize the jaxb context using spring and wire it
>> > into
>> > > your service?
>> > >
>> > > I presume that that its the jaxb context initialization that is taking
>> > all
>> > > the time?
>> > >
>> > > On Wed, Oct 22, 2008 at 2:04 PM, Alp Timurhan Çevik <
>> atcevik@gmail.com
>> > > >wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > I need to connect to a server that has an HL7 v3 based wsdl document
>> > > which
>> > > > has tens of thousands of different types. I have a server
>> application
>> > > which
>> > > > listens for some events and sends data to these web services.
>> > > >
>> > > > I am currently having performance problem at startup. It takes 5-10
>> > > minutes
>> > > > for the service to complete jaxb initialization (I guess). After the
>> > > first
>> > > > call, things run smoothly, responding at max 10 seconds.
>> > > >
>> > > > In order to solve the problem, I have began to send a dummy message
>> at
>> > > the
>> > > > startup, which seemed like solving my performance problem at
>> startup,
>> > but
>> > > > later on I found out that after some inactivity time, the first
>> message
>> > > > problem just resurrects. I thought as I do have a lot of
>> > classdefinitions
>> > > > from these wsdls, the noclassgc jvm parameter could solve my
>> problem,
>> > but
>> > > > alas it did not. Actually it is not an easy problem to test, also,
>> > > because
>> > > > I
>> > > > have to wait for the timeout.
>> > > >
>> > > > I am thinking of sending the dummy messages regularly, but the
>> server
>> > > > application I run is also running some simple web services which
>> sends
>> > > data
>> > > > to hl7 v3 (the huge ones) web services and replies to the users
>> > according
>> > > > to
>> > > > the response from hl7 v3s.
>> > > >
>> > > > I have also tried sxj but still startup performance is miserable.
>> > > >
>> > > > Any suggestions ?
>> > > >
>> > > > Best regards,
>> > > > Alp Timurhan Çevik
>> > > >
>> > >
>> >
>>
>
>
Re: Huge wsdl (HL7 v3) performance problem (a.k.a how jaxb is ruining my life)
Posted by Alp Timurhan Çevik <at...@gmail.com>.
The message is somethink between 20K-50K, the actual call does not occur on
getting the port using port = service.getMCCIAR000001TRPort() , occurs on
port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message)
conversionResult). So the transport delay /lag is not present yet (I guess).
I am also using threading, and by the way, the performance problem is not
present after the first call (at least during some time, in order to make
things complicated). So I do not think the issue is due to creating several
instances.
Could it be something related to wsdl parsing ? I do not know. All I can
think of is garbage collection of classes after some amount of time, but
still I am nowhere.
>
On Wed, Oct 22, 2008 at 4:40 PM, Adrian Corcoran
<ad...@gmail.com>wrote:
> This is perhaps got to do with the way that you are consuming the services.
>
> port = service.getMCCIAR000001TRPort()
>
> You probably only need to create this once and you should the be able to
> re-use it (be careful of you threading model thou).
>
> The call port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message), is
> the
> time being lost over the wire, or in marshalling the message, what type of
> size is the message?
>
> On Wed, Oct 22, 2008 at 2:31 PM, Alp Timurhan Çevik <atcevik@gmail.com
> >wrote:
>
> > Adrian,
> >
> > I am not very familiar with jaxb, so I cannot give a yes or no answer,
> but
> > let me try to explain.
> >
> > While debugging, I get to the part where jaxb generated objects is
> > populated
> > fastly, but the part where the actual message sending occurs, the
> > performance is miserable at first call.
> >
> > I am not using Spring. The initialization is like
> >
> >
> > org.apache.cxf.common.logging.LogUtils.setLoggerClass(Log4jLogger.class);
> > SaglikNetAdapterWebService serviceImpl = new XWebService();
> > JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
> > svrFactory.setServiceBean(serviceImpl);
> > svrFactory.setServiceClass(XWebServiceInterface.class);
> >
> >
> >
> svrFactory.setAddress(PlainWebServiceConstants.getString("ServerService.ServiceRealAdress"));
> >
> >
> >
> svrFactory.setPublishedEndpointUrl(PlainWebServiceConstants.getString("ServerService.WsdlDeclaredAdress"));
> > svrFactory.getInInterceptors().add(new
> > PlainMessagePersistenceLoggerInterceptor());
> > enableWsdlValidation(svrFactory);
> > Server server = svrFactory.create();
> >
> > Calling the service is
> >
> > MCCIAR000001TRPortType port;
> > service.setHandlerResolver(new
> HL7InsertMessageHandlerResolver(uuid,
> > ServiceClientDbUtils.getSessionFactory(),
> > transaction));
> > port = service.getMCCIAR000001TRPort();
> > port = ServiceClientUtils.changeDestinationAdress(port,
> > transaction);
> > port =
> > ServiceClientSecurityHeaderUtils.createSecurityHeader(userInfo,
> paketTuru,
> > uuid, port);
> >
> > which is the first part where it takes a lot to execute. Especially
> > port = service.getMCCIAR000001TRPort();
> >
> >
> > ...
> > ...
> > ...
> > ...
> > return port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message)
> > conversionResult);
> >
> > part also takes time.
> >
> > Also, wsdl validation occurs in no time, it even is very fast on first
> > call.
> >
> >
> > P.S. I recognized that I really do not know if the problem is due to
> Jaxb,
> > so I apologize from jaxb because of the subject. I should change it to
> how
> > something I do not even know ruins my life.
> >
> >
> >
> > On Wed, Oct 22, 2008 at 4:15 PM, Adrian Corcoran
> > <ad...@gmail.com>wrote:
> >
> > > Is it possible to initialize the jaxb context using spring and wire it
> > into
> > > your service?
> > >
> > > I presume that that its the jaxb context initialization that is taking
> > all
> > > the time?
> > >
> > > On Wed, Oct 22, 2008 at 2:04 PM, Alp Timurhan Çevik <atcevik@gmail.com
> > > >wrote:
> > >
> > > > Hello,
> > > >
> > > > I need to connect to a server that has an HL7 v3 based wsdl document
> > > which
> > > > has tens of thousands of different types. I have a server application
> > > which
> > > > listens for some events and sends data to these web services.
> > > >
> > > > I am currently having performance problem at startup. It takes 5-10
> > > minutes
> > > > for the service to complete jaxb initialization (I guess). After the
> > > first
> > > > call, things run smoothly, responding at max 10 seconds.
> > > >
> > > > In order to solve the problem, I have began to send a dummy message
> at
> > > the
> > > > startup, which seemed like solving my performance problem at startup,
> > but
> > > > later on I found out that after some inactivity time, the first
> message
> > > > problem just resurrects. I thought as I do have a lot of
> > classdefinitions
> > > > from these wsdls, the noclassgc jvm parameter could solve my problem,
> > but
> > > > alas it did not. Actually it is not an easy problem to test, also,
> > > because
> > > > I
> > > > have to wait for the timeout.
> > > >
> > > > I am thinking of sending the dummy messages regularly, but the server
> > > > application I run is also running some simple web services which
> sends
> > > data
> > > > to hl7 v3 (the huge ones) web services and replies to the users
> > according
> > > > to
> > > > the response from hl7 v3s.
> > > >
> > > > I have also tried sxj but still startup performance is miserable.
> > > >
> > > > Any suggestions ?
> > > >
> > > > Best regards,
> > > > Alp Timurhan Çevik
> > > >
> > >
> >
>
Re: Huge wsdl (HL7 v3) performance problem (a.k.a how jaxb is ruining my life)
Posted by Adrian Corcoran <ad...@gmail.com>.
This is perhaps got to do with the way that you are consuming the services.
port = service.getMCCIAR000001TRPort()
You probably only need to create this once and you should the be able to
re-use it (be careful of you threading model thou).
The call port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message), is the
time being lost over the wire, or in marshalling the message, what type of
size is the message?
On Wed, Oct 22, 2008 at 2:31 PM, Alp Timurhan Çevik <at...@gmail.com>wrote:
> Adrian,
>
> I am not very familiar with jaxb, so I cannot give a yes or no answer, but
> let me try to explain.
>
> While debugging, I get to the part where jaxb generated objects is
> populated
> fastly, but the part where the actual message sending occurs, the
> performance is miserable at first call.
>
> I am not using Spring. The initialization is like
>
>
> org.apache.cxf.common.logging.LogUtils.setLoggerClass(Log4jLogger.class);
> SaglikNetAdapterWebService serviceImpl = new XWebService();
> JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
> svrFactory.setServiceBean(serviceImpl);
> svrFactory.setServiceClass(XWebServiceInterface.class);
>
>
> svrFactory.setAddress(PlainWebServiceConstants.getString("ServerService.ServiceRealAdress"));
>
>
> svrFactory.setPublishedEndpointUrl(PlainWebServiceConstants.getString("ServerService.WsdlDeclaredAdress"));
> svrFactory.getInInterceptors().add(new
> PlainMessagePersistenceLoggerInterceptor());
> enableWsdlValidation(svrFactory);
> Server server = svrFactory.create();
>
> Calling the service is
>
> MCCIAR000001TRPortType port;
> service.setHandlerResolver(new HL7InsertMessageHandlerResolver(uuid,
> ServiceClientDbUtils.getSessionFactory(),
> transaction));
> port = service.getMCCIAR000001TRPort();
> port = ServiceClientUtils.changeDestinationAdress(port,
> transaction);
> port =
> ServiceClientSecurityHeaderUtils.createSecurityHeader(userInfo, paketTuru,
> uuid, port);
>
> which is the first part where it takes a lot to execute. Especially
> port = service.getMCCIAR000001TRPort();
>
>
> ...
> ...
> ...
> ...
> return port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message)
> conversionResult);
>
> part also takes time.
>
> Also, wsdl validation occurs in no time, it even is very fast on first
> call.
>
>
> P.S. I recognized that I really do not know if the problem is due to Jaxb,
> so I apologize from jaxb because of the subject. I should change it to how
> something I do not even know ruins my life.
>
>
>
> On Wed, Oct 22, 2008 at 4:15 PM, Adrian Corcoran
> <ad...@gmail.com>wrote:
>
> > Is it possible to initialize the jaxb context using spring and wire it
> into
> > your service?
> >
> > I presume that that its the jaxb context initialization that is taking
> all
> > the time?
> >
> > On Wed, Oct 22, 2008 at 2:04 PM, Alp Timurhan Çevik <atcevik@gmail.com
> > >wrote:
> >
> > > Hello,
> > >
> > > I need to connect to a server that has an HL7 v3 based wsdl document
> > which
> > > has tens of thousands of different types. I have a server application
> > which
> > > listens for some events and sends data to these web services.
> > >
> > > I am currently having performance problem at startup. It takes 5-10
> > minutes
> > > for the service to complete jaxb initialization (I guess). After the
> > first
> > > call, things run smoothly, responding at max 10 seconds.
> > >
> > > In order to solve the problem, I have began to send a dummy message at
> > the
> > > startup, which seemed like solving my performance problem at startup,
> but
> > > later on I found out that after some inactivity time, the first message
> > > problem just resurrects. I thought as I do have a lot of
> classdefinitions
> > > from these wsdls, the noclassgc jvm parameter could solve my problem,
> but
> > > alas it did not. Actually it is not an easy problem to test, also,
> > because
> > > I
> > > have to wait for the timeout.
> > >
> > > I am thinking of sending the dummy messages regularly, but the server
> > > application I run is also running some simple web services which sends
> > data
> > > to hl7 v3 (the huge ones) web services and replies to the users
> according
> > > to
> > > the response from hl7 v3s.
> > >
> > > I have also tried sxj but still startup performance is miserable.
> > >
> > > Any suggestions ?
> > >
> > > Best regards,
> > > Alp Timurhan Çevik
> > >
> >
>
Re: Huge wsdl (HL7 v3) performance problem (a.k.a how jaxb is ruining my life)
Posted by Alp Timurhan Çevik <at...@gmail.com>.
Adrian,
I am not very familiar with jaxb, so I cannot give a yes or no answer, but
let me try to explain.
While debugging, I get to the part where jaxb generated objects is populated
fastly, but the part where the actual message sending occurs, the
performance is miserable at first call.
I am not using Spring. The initialization is like
org.apache.cxf.common.logging.LogUtils.setLoggerClass(Log4jLogger.class);
SaglikNetAdapterWebService serviceImpl = new XWebService();
JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
svrFactory.setServiceBean(serviceImpl);
svrFactory.setServiceClass(XWebServiceInterface.class);
svrFactory.setAddress(PlainWebServiceConstants.getString("ServerService.ServiceRealAdress"));
svrFactory.setPublishedEndpointUrl(PlainWebServiceConstants.getString("ServerService.WsdlDeclaredAdress"));
svrFactory.getInInterceptors().add(new
PlainMessagePersistenceLoggerInterceptor());
enableWsdlValidation(svrFactory);
Server server = svrFactory.create();
Calling the service is
MCCIAR000001TRPortType port;
service.setHandlerResolver(new HL7InsertMessageHandlerResolver(uuid,
ServiceClientDbUtils.getSessionFactory(),
transaction));
port = service.getMCCIAR000001TRPort();
port = ServiceClientUtils.changeDestinationAdress(port,
transaction);
port =
ServiceClientSecurityHeaderUtils.createSecurityHeader(userInfo, paketTuru,
uuid, port);
which is the first part where it takes a lot to execute. Especially
port = service.getMCCIAR000001TRPort();
...
...
...
...
return port.mcciAR000001TRMCCIIN000001TR((MCCIIN000001TR01Message)
conversionResult);
part also takes time.
Also, wsdl validation occurs in no time, it even is very fast on first call.
P.S. I recognized that I really do not know if the problem is due to Jaxb,
so I apologize from jaxb because of the subject. I should change it to how
something I do not even know ruins my life.
On Wed, Oct 22, 2008 at 4:15 PM, Adrian Corcoran
<ad...@gmail.com>wrote:
> Is it possible to initialize the jaxb context using spring and wire it into
> your service?
>
> I presume that that its the jaxb context initialization that is taking all
> the time?
>
> On Wed, Oct 22, 2008 at 2:04 PM, Alp Timurhan Çevik <atcevik@gmail.com
> >wrote:
>
> > Hello,
> >
> > I need to connect to a server that has an HL7 v3 based wsdl document
> which
> > has tens of thousands of different types. I have a server application
> which
> > listens for some events and sends data to these web services.
> >
> > I am currently having performance problem at startup. It takes 5-10
> minutes
> > for the service to complete jaxb initialization (I guess). After the
> first
> > call, things run smoothly, responding at max 10 seconds.
> >
> > In order to solve the problem, I have began to send a dummy message at
> the
> > startup, which seemed like solving my performance problem at startup, but
> > later on I found out that after some inactivity time, the first message
> > problem just resurrects. I thought as I do have a lot of classdefinitions
> > from these wsdls, the noclassgc jvm parameter could solve my problem, but
> > alas it did not. Actually it is not an easy problem to test, also,
> because
> > I
> > have to wait for the timeout.
> >
> > I am thinking of sending the dummy messages regularly, but the server
> > application I run is also running some simple web services which sends
> data
> > to hl7 v3 (the huge ones) web services and replies to the users according
> > to
> > the response from hl7 v3s.
> >
> > I have also tried sxj but still startup performance is miserable.
> >
> > Any suggestions ?
> >
> > Best regards,
> > Alp Timurhan Çevik
> >
>
Re: Huge wsdl (HL7 v3) performance problem (a.k.a how jaxb is ruining my life)
Posted by Adrian Corcoran <ad...@gmail.com>.
Is it possible to initialize the jaxb context using spring and wire it into
your service?
I presume that that its the jaxb context initialization that is taking all
the time?
On Wed, Oct 22, 2008 at 2:04 PM, Alp Timurhan Çevik <at...@gmail.com>wrote:
> Hello,
>
> I need to connect to a server that has an HL7 v3 based wsdl document which
> has tens of thousands of different types. I have a server application which
> listens for some events and sends data to these web services.
>
> I am currently having performance problem at startup. It takes 5-10 minutes
> for the service to complete jaxb initialization (I guess). After the first
> call, things run smoothly, responding at max 10 seconds.
>
> In order to solve the problem, I have began to send a dummy message at the
> startup, which seemed like solving my performance problem at startup, but
> later on I found out that after some inactivity time, the first message
> problem just resurrects. I thought as I do have a lot of classdefinitions
> from these wsdls, the noclassgc jvm parameter could solve my problem, but
> alas it did not. Actually it is not an easy problem to test, also, because
> I
> have to wait for the timeout.
>
> I am thinking of sending the dummy messages regularly, but the server
> application I run is also running some simple web services which sends data
> to hl7 v3 (the huge ones) web services and replies to the users according
> to
> the response from hl7 v3s.
>
> I have also tried sxj but still startup performance is miserable.
>
> Any suggestions ?
>
> Best regards,
> Alp Timurhan Çevik
>