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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]>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 <
>> [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
>>> >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
>>> > <[EMAIL PROTECTED]>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 <
>>> [EMAIL PROTECTED]
>>> > > >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
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>