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