You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by "stephan.lux" <st...@directline.de> on 2006/12/19 11:50:45 UTC
Severe issues while load testing
Hi,
we are planing to use an esb technology in a productive application and so
we have started with this topic and evaluating service mix 3.0. Therefore I
have created two simple prototypes with the following components:
SA1
---
Quartz Timer (LW-SU) -> Groovy Script (LW-SU) -> XPathSplitter (EIP-SU) ->
XsltComponent (LW-SU) -> ContentBasedRouter (EIP-SU) -> FileWriter (LW-SU) |
SOAP Provider (HTTP-SU)
SA2
---
FilePoller (LW-SU) | SOAP Consumer (HTTP-SU) -> XsltComponent (LW-SU) ->
Groovy Script (LW-SU)
The SA1 is reading some entries database entries in the groovy script and
sends them to the SA2 endpoints (filepoller/soap endpoint), which performs
an update of the job table. Both service assembies are deployed into the
'deploy' directory of the standalone container, so I use the default
configuration of the servicemix 3.0 distribution.
All works fine, if I send some jobs through the esb, but if I start a small
load test (250 jobs) the processing stops in different steps, so I can see
in a tracing component that some jobs 'hanging' e.g. in the XPathSplitter or
Groovy Script Component. Only round about 30 jobs are processed
successfully, the other are lost in the esb! Very strange is, that I can see
files of the load test in the directory that were not processed, but if I
enter a new job to the database it would be recognized and processed!
So at this point of view the evaluation is collapsed, because we can not use
it into a productive application. Maybe it is only a configuration problem,
but I have no idea, on which screw I have to adjust.
So I am thankful for each tip or hint.
Stephan
--
View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a7945081
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Severe issues while load testing
Posted by "stephan.lux" <st...@directline.de>.
stephan.lux wrote:
>
>
> gnodet wrote:
>>
>> Can you track where these objects are allocated from ?
>>
> Yes, Jprofiler is realy a fine tool :-)
> The most of the instances are created by the microsoft mssql driver. As
> you can see in the allocation reports, a lot of objects were not destroyed
> that are created by the groovy component. Maybe a hint that here is the
> root of the memory leak? The database access via the mssql jdbc driver is
> done there...
>
> I have also added two reports, that are showing how many objects are left
> after processing some jobs. Sometimes - as written before - some of the
> jobs are not processed successfully without returning an error (I have
> also checked the debug log). In this case some mb are left in memory. The
> report 'Recorded_Objects_400_jobs_17_failed.html' shows these classes.
>
> I don't know where and why the messages are disapearing, but I still keep
> on profiling and searching...
>
> http://www.nabble.com/file/5289/JProfiler_Results.zip
> JProfiler_Results.zip
>
> Stephan
>
--
View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8158869
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Severe issues while load testing
Posted by Guillaume Nodet <gn...@gmail.com>.
On 1/3/07, stephan.lux <st...@directline.de> wrote:
>
>
> Hi Guillaume,
> now I have used JProfiler and found the main problem why my loadtest fails
> with out of memory messages... The reason is simple, due to that the timer
> fires again while the jobs were retrieved, a lot of more messages are send
> to the bus. That was to much load for the eip - xpath-splitter, so that I am
> running out of memory :-)
>
> But it seams that there is still an other memory leak, because after each
> run some megabyte more are left in memory. Even injecting the garbage
> collector does not free them. I can see in JProfiler, that some thousend
> java.net.Inet4Address objects were created but not destroyed. What do you
> think? Maybe a memory leak in the http provider?
Can you track where these objects are allocated from ?
>
> Attached you will find the jprofiler report before and after my test run.
> http://www.nabble.com/file/5271/Deadlock_Detection_Graph.zip
> Deadlock_Detection_Graph.zip
>
> One more question: The JProfiler deadlock detector reports sometimes while
> testing that some threads are blocked while accessing a common resource or
> object. In this case it is the CondVar class of the
> edu.emory.mathcs.backport.java.util.concurrent.locks package. Is this a kind
> of in-memory database/store?
These are thread from thread pools, waiting for jobs to process.
So it's fine.
>
> Cheers,
> Stephan
>
>
> gnodet wrote:
> >
> > If you run OOM after a certain time, this means you have a memory leak
> > somewhere ... It may be because one of the components never answers
> > to exchanges, or one never receives them ... (do you have hand-written
> > components ?)
> > Another reason could be that there is lots of messages injected in the
> > container,
> > but they are processed slowly, hence after a while, they can't all be kept
> > in
> > memory: this can happen if you use a jms consumer which receives lots
> > of messages.
> >
> > You should try configuring a profile and see which objects are kept in
> > memory.
> > Also, to make sure that this is a memory leak somewhere, make sure you
> > inject messages into the bus at a slow rate, so that they can be processed
> > in a timely manner (to avoid keeping lots of waiting messages in memory).
> >
> > On 1/2/07, stephan.lux <st...@directline.de> wrote:
> >>
> >>
> >> stephan.lux wrote:
> >> >
> >> > Sure, the performance is suffering if you do a lot of xml conversions,
> >> but
> >> > in this cas I only use a small 300 byte xml file and the xslt
> >> > transformation only copies the content into a new cover.
> >> >
> >> > The blocking ressource is the system memory, 512 MB is not enough on
> >> > windows. Has anyone run some loadtests on unix/linux with more than
> >> 5000
> >> > jobs? How many memory was used?
> >> >
> >> > Cheers
> >> > Stephan
> >> >
> >> >
> >> > gnodet wrote:
> >> >>
> >> >> ServiceMix performance mainly depends on the processing performed,
> >> >> either directly or indirectly (scripting may be slower than java, lots
> >> >> of xml conversions ...).
> >> >> Make sure the log level is set to INFO or more.
> >> >> And also make sure your CPU is used at 100%, else it means
> >> >> there is a blocking resource (number of threads, IO ...)
> >> >>
> >> >> On 12/29/06, stephan.lux <st...@directline.de> wrote:
> >> >>>
> >> >>>
> >> >>> stephan.lux wrote:
> >> >>> >
> >> >>> > Hi Guillaume,
> >> >>> >
> >> >>> > I have now all of your tipps applied and rerun the test with 5.000
> >> >>> jobs.
> >> >>> > It failes again this out of memory messages and the processing
> >> stops.
> >> >>> So I
> >> >>> > have seperated the service assemblies on two boxes with each 512MB
> >> of
> >> >>> RAM
> >> >>> > for Service Mix. On one maschine once again out of memory messages
> >> are
> >> >>> > thrown, but the most of the jobs could be processed. So it seams,
> >> that
> >> >>> the
> >> >>> > script component needs a lot of memory...
> >> >>> >
> >> >>> > But for the processing servicemix needs round about 8 hours! That
> >> is
> >> >>> not
> >> >>> > realy acceptable for us, so do you have any more tuning tipps for
> >> me?
> >> >>> >
> >> >>> >
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> View this message in context:
> >> >>>
> >> http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8088779
> >> >>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Cheers,
> >> >> Guillaume Nodet
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8122637
> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
> >
> </qoute>
> --
> View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8144674
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
Re: Severe issues while load testing
Posted by "stephan.lux" <st...@directline.de>.
Hi Guillaume,
now I have used JProfiler and found the main problem why my loadtest fails
with out of memory messages... The reason is simple, due to that the timer
fires again while the jobs were retrieved, a lot of more messages are send
to the bus. That was to much load for the eip - xpath-splitter, so that I am
running out of memory :-)
But it seams that there is still an other memory leak, because after each
run some megabyte more are left in memory. Even injecting the garbage
collector does not free them. I can see in JProfiler, that some thousend
java.net.Inet4Address objects were created but not destroyed. What do you
think? Maybe a memory leak in the http provider?
Attached you will find the jprofiler report before and after my test run.
http://www.nabble.com/file/5271/Deadlock_Detection_Graph.zip
Deadlock_Detection_Graph.zip
One more question: The JProfiler deadlock detector reports sometimes while
testing that some threads are blocked while accessing a common resource or
object. In this case it is the CondVar class of the
edu.emory.mathcs.backport.java.util.concurrent.locks package. Is this a kind
of in-memory database/store?
Cheers,
Stephan
gnodet wrote:
>
> If you run OOM after a certain time, this means you have a memory leak
> somewhere ... It may be because one of the components never answers
> to exchanges, or one never receives them ... (do you have hand-written
> components ?)
> Another reason could be that there is lots of messages injected in the
> container,
> but they are processed slowly, hence after a while, they can't all be kept
> in
> memory: this can happen if you use a jms consumer which receives lots
> of messages.
>
> You should try configuring a profile and see which objects are kept in
> memory.
> Also, to make sure that this is a memory leak somewhere, make sure you
> inject messages into the bus at a slow rate, so that they can be processed
> in a timely manner (to avoid keeping lots of waiting messages in memory).
>
> On 1/2/07, stephan.lux <st...@directline.de> wrote:
>>
>>
>> stephan.lux wrote:
>> >
>> > Sure, the performance is suffering if you do a lot of xml conversions,
>> but
>> > in this cas I only use a small 300 byte xml file and the xslt
>> > transformation only copies the content into a new cover.
>> >
>> > The blocking ressource is the system memory, 512 MB is not enough on
>> > windows. Has anyone run some loadtests on unix/linux with more than
>> 5000
>> > jobs? How many memory was used?
>> >
>> > Cheers
>> > Stephan
>> >
>> >
>> > gnodet wrote:
>> >>
>> >> ServiceMix performance mainly depends on the processing performed,
>> >> either directly or indirectly (scripting may be slower than java, lots
>> >> of xml conversions ...).
>> >> Make sure the log level is set to INFO or more.
>> >> And also make sure your CPU is used at 100%, else it means
>> >> there is a blocking resource (number of threads, IO ...)
>> >>
>> >> On 12/29/06, stephan.lux <st...@directline.de> wrote:
>> >>>
>> >>>
>> >>> stephan.lux wrote:
>> >>> >
>> >>> > Hi Guillaume,
>> >>> >
>> >>> > I have now all of your tipps applied and rerun the test with 5.000
>> >>> jobs.
>> >>> > It failes again this out of memory messages and the processing
>> stops.
>> >>> So I
>> >>> > have seperated the service assemblies on two boxes with each 512MB
>> of
>> >>> RAM
>> >>> > for Service Mix. On one maschine once again out of memory messages
>> are
>> >>> > thrown, but the most of the jobs could be processed. So it seams,
>> that
>> >>> the
>> >>> > script component needs a lot of memory...
>> >>> >
>> >>> > But for the processing servicemix needs round about 8 hours! That
>> is
>> >>> not
>> >>> > realy acceptable for us, so do you have any more tuning tipps for
>> me?
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> View this message in context:
>> >>>
>> http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8088779
>> >>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Guillaume Nodet
>> >>
>> >>
>> >
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8122637
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
</qoute>
--
View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8144674
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Severe issues while load testing
Posted by Guillaume Nodet <gn...@gmail.com>.
If you run OOM after a certain time, this means you have a memory leak
somewhere ... It may be because one of the components never answers
to exchanges, or one never receives them ... (do you have hand-written
components ?)
Another reason could be that there is lots of messages injected in the
container,
but they are processed slowly, hence after a while, they can't all be kept in
memory: this can happen if you use a jms consumer which receives lots
of messages.
You should try configuring a profile and see which objects are kept in memory.
Also, to make sure that this is a memory leak somewhere, make sure you
inject messages into the bus at a slow rate, so that they can be processed
in a timely manner (to avoid keeping lots of waiting messages in memory).
On 1/2/07, stephan.lux <st...@directline.de> wrote:
>
>
> stephan.lux wrote:
> >
> > Sure, the performance is suffering if you do a lot of xml conversions, but
> > in this cas I only use a small 300 byte xml file and the xslt
> > transformation only copies the content into a new cover.
> >
> > The blocking ressource is the system memory, 512 MB is not enough on
> > windows. Has anyone run some loadtests on unix/linux with more than 5000
> > jobs? How many memory was used?
> >
> > Cheers
> > Stephan
> >
> >
> > gnodet wrote:
> >>
> >> ServiceMix performance mainly depends on the processing performed,
> >> either directly or indirectly (scripting may be slower than java, lots
> >> of xml conversions ...).
> >> Make sure the log level is set to INFO or more.
> >> And also make sure your CPU is used at 100%, else it means
> >> there is a blocking resource (number of threads, IO ...)
> >>
> >> On 12/29/06, stephan.lux <st...@directline.de> wrote:
> >>>
> >>>
> >>> stephan.lux wrote:
> >>> >
> >>> > Hi Guillaume,
> >>> >
> >>> > I have now all of your tipps applied and rerun the test with 5.000
> >>> jobs.
> >>> > It failes again this out of memory messages and the processing stops.
> >>> So I
> >>> > have seperated the service assemblies on two boxes with each 512MB of
> >>> RAM
> >>> > for Service Mix. On one maschine once again out of memory messages are
> >>> > thrown, but the most of the jobs could be processed. So it seams, that
> >>> the
> >>> > script component needs a lot of memory...
> >>> >
> >>> > But for the processing servicemix needs round about 8 hours! That is
> >>> not
> >>> > realy acceptable for us, so do you have any more tuning tipps for me?
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context:
> >>> http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8088779
> >>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
> >>>
> >>>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >>
> >>
> >
>
>
> --
> View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8122637
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
Re: Severe issues while load testing
Posted by "stephan.lux" <st...@directline.de>.
stephan.lux wrote:
>
> Sure, the performance is suffering if you do a lot of xml conversions, but
> in this cas I only use a small 300 byte xml file and the xslt
> transformation only copies the content into a new cover.
>
> The blocking ressource is the system memory, 512 MB is not enough on
> windows. Has anyone run some loadtests on unix/linux with more than 5000
> jobs? How many memory was used?
>
> Cheers
> Stephan
>
>
> gnodet wrote:
>>
>> ServiceMix performance mainly depends on the processing performed,
>> either directly or indirectly (scripting may be slower than java, lots
>> of xml conversions ...).
>> Make sure the log level is set to INFO or more.
>> And also make sure your CPU is used at 100%, else it means
>> there is a blocking resource (number of threads, IO ...)
>>
>> On 12/29/06, stephan.lux <st...@directline.de> wrote:
>>>
>>>
>>> stephan.lux wrote:
>>> >
>>> > Hi Guillaume,
>>> >
>>> > I have now all of your tipps applied and rerun the test with 5.000
>>> jobs.
>>> > It failes again this out of memory messages and the processing stops.
>>> So I
>>> > have seperated the service assemblies on two boxes with each 512MB of
>>> RAM
>>> > for Service Mix. On one maschine once again out of memory messages are
>>> > thrown, but the most of the jobs could be processed. So it seams, that
>>> the
>>> > script component needs a lot of memory...
>>> >
>>> > But for the processing servicemix needs round about 8 hours! That is
>>> not
>>> > realy acceptable for us, so do you have any more tuning tipps for me?
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8088779
>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>>
>>
>
--
View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8122637
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Severe issues while load testing
Posted by Guillaume Nodet <gn...@gmail.com>.
ServiceMix performance mainly depends on the processing performed,
either directly or indirectly (scripting may be slower than java, lots
of xml conversions ...).
Make sure the log level is set to INFO or more.
And also make sure your CPU is used at 100%, else it means
there is a blocking resource (number of threads, IO ...)
On 12/29/06, stephan.lux <st...@directline.de> wrote:
>
>
> stephan.lux wrote:
> >
> > Hi Guillaume,
> >
> > I have now all of your tipps applied and rerun the test with 5.000 jobs.
> > It failes again this out of memory messages and the processing stops. So I
> > have seperated the service assemblies on two boxes with each 512MB of RAM
> > for Service Mix. On one maschine once again out of memory messages are
> > thrown, but the most of the jobs could be processed. So it seams, that the
> > script component needs a lot of memory...
> >
> > But for the processing servicemix needs round about 8 hours! That is not
> > realy acceptable for us, so do you have any more tuning tipps for me?
> >
> >
>
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8088779
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
Re: Severe issues while load testing
Posted by "stephan.lux" <st...@directline.de>.
stephan.lux wrote:
>
> Hi Guillaume,
>
> I have now all of your tipps applied and rerun the test with 5.000 jobs.
> It failes again this out of memory messages and the processing stops. So I
> have seperated the service assemblies on two boxes with each 512MB of RAM
> for Service Mix. On one maschine once again out of memory messages are
> thrown, but the most of the jobs could be processed. So it seams, that the
> script component needs a lot of memory...
>
> But for the processing servicemix needs round about 8 hours! That is not
> realy acceptable for us, so do you have any more tuning tipps for me?
>
>
--
View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a8088779
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Severe issues while load testing
Posted by Guillaume Nodet <gn...@gmail.com>.
On 12/20/06, stephan.lux <st...@directline.de> wrote:
>
>
> stephan.lux wrote:
> >
> > Hi Guillaume,
> >
> > I have tried both:
> >
> > After increasing the workmanager threadpool i have received "Failed to
> > schedule work: java.lang.OutOfMemoryError: unable to create new native
> > thread" messages.
> >
> > So I have downloaded the latest 3.1 snapshot, applied the thread pool
> > settings of the named page and the VM crashes also by processing 2000 job
> > with an out of memory message. So I have limited the thread pool to 500
> > and it works.
Creating new threads is quite memory intensive.
Using 3.1-SNAPSHOT, thread pools are created per component, so you'd
better keep the amount not too high (32 / 64 should work well).
> >
> > What do you think about the change of my lightweight components to the new
> > file/ftp bindings? Does this bring a performance advantage? I have also
> > found a new servicemix-script component, but unfortunately no
> > documentation about it. Can you provide me a short sample configuration
> > how I can call a groovy script?
The lightweight components are not heavily worked on and you should
use the new components if possible.
For the script component, you can look at the junit test cases available
at http://fisheye3.cenqua.com/browse/servicemix/trunk/deployables/serviceengines/servicemix-script/src/test/resources
> >
> > Thanks,
> > Stephan
> >
> >
> > gnodet wrote:
> >>
> >> Use 3.1-SNAPSHOT and configure the thread pools to suit
> >> your needs (http://servicemix.goopen.org/site/thread-pools.html).
> >>
> >> Alternatively, you can grow the number of threads in the WorkManager
> >> (for ServiceMix 3.0), but 3.1 will certainly be more robust.
> >>
> >
>
>
> --
> View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a7993548
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
Re: Severe issues while load testing
Posted by "stephan.lux" <st...@directline.de>.
stephan.lux wrote:
>
> Hi Guillaume,
>
> I have tried both:
>
> After increasing the workmanager threadpool i have received "Failed to
> schedule work: java.lang.OutOfMemoryError: unable to create new native
> thread" messages.
>
> So I have downloaded the latest 3.1 snapshot, applied the thread pool
> settings of the named page and the VM crashes also by processing 2000 job
> with an out of memory message. So I have limited the thread pool to 500
> and it works.
>
> What do you think about the change of my lightweight components to the new
> file/ftp bindings? Does this bring a performance advantage? I have also
> found a new servicemix-script component, but unfortunately no
> documentation about it. Can you provide me a short sample configuration
> how I can call a groovy script?
>
> Thanks,
> Stephan
>
>
> gnodet wrote:
>>
>> Use 3.1-SNAPSHOT and configure the thread pools to suit
>> your needs (http://servicemix.goopen.org/site/thread-pools.html).
>>
>> Alternatively, you can grow the number of threads in the WorkManager
>> (for ServiceMix 3.0), but 3.1 will certainly be more robust.
>>
>
--
View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a7993548
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Severe issues while load testing
Posted by Guillaume Nodet <gn...@gmail.com>.
Use 3.1-SNAPSHOT and configure the thread pools to suit
your needs (http://servicemix.goopen.org/site/thread-pools.html).
Alternatively, you can grow the number of threads in the WorkManager
(for ServiceMix 3.0), but 3.1 will certainly be more robust.
On 12/19/06, stephan.lux <st...@directline.de> wrote:
>
> Hi,
> we are planing to use an esb technology in a productive application and so
> we have started with this topic and evaluating service mix 3.0. Therefore I
> have created two simple prototypes with the following components:
>
> SA1
> ---
> Quartz Timer (LW-SU) -> Groovy Script (LW-SU) -> XPathSplitter (EIP-SU) ->
> XsltComponent (LW-SU) -> ContentBasedRouter (EIP-SU) -> FileWriter (LW-SU) |
> SOAP Provider (HTTP-SU)
>
> SA2
> ---
> FilePoller (LW-SU) | SOAP Consumer (HTTP-SU) -> XsltComponent (LW-SU) ->
> Groovy Script (LW-SU)
>
> The SA1 is reading some entries database entries in the groovy script and
> sends them to the SA2 endpoints (filepoller/soap endpoint), which performs
> an update of the job table. Both service assembies are deployed into the
> 'deploy' directory of the standalone container, so I use the default
> configuration of the servicemix 3.0 distribution.
>
> All works fine, if I send some jobs through the esb, but if I start a small
> load test (250 jobs) the processing stops in different steps, so I can see
> in a tracing component that some jobs 'hanging' e.g. in the XPathSplitter or
> Groovy Script Component. Only round about 30 jobs are processed
> successfully, the other are lost in the esb! Very strange is, that I can see
> files of the load test in the directory that were not processed, but if I
> enter a new job to the database it would be recognized and processed!
>
> So at this point of view the evaluation is collapsed, because we can not use
> it into a productive application. Maybe it is only a configuration problem,
> but I have no idea, on which screw I have to adjust.
>
> So I am thankful for each tip or hint.
> Stephan
> --
> View this message in context: http://www.nabble.com/Severe-issues-while-load-testing-tf2845236s12049.html#a7945081
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet