Skip to main content

Generic framework issues

10 replies [Last post]
Anonymous

Hi Maxim,

I've started review generic communication execution framework and submitted
several issues already:
https://cqme.dev.java.net/issues/show_bug.cgi?id=135
https://cqme.dev.java.net/issues/show_bug.cgi?id=136
https://cqme.dev.java.net/issues/show_bug.cgi?id=137

Please review them and provide your comments.

Thanks,
Alexander

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Vladimir Sizikov

Hi Alexander,

On Fri, May 11, 2007 at 06:25:13PM +0400, Alexander Alexeev wrote:
> I have tried to run CDC TCK with different comm clients today:
> DatagramSocketCommClient, MidHttpCommClient and SocketCommClient.
> Unfortunately I can observe the same performance degradation for all
> of them. I will try to find the bottle neck.

This is very serious and requires our immediate attention. With
serious performance degradations we cannot easily swtich to the new
Agent and communications.

Could you please work with Maxim with as much effort as you can put
into this problem?

Also, could you please provide some info, description (and possibly
scripts) on how did you setup the whole thing? I'll probably try to
look at it as well, and don't want to spend too much time going the
same path you've already completed.

Thanks,
--Vladimir

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Hi Maxim, Alexander,

Hurray! I was able to find the bottleneck. :)

Take a look at BaseClientExecutionService.exchangeBytes(), you'll
find a couple of SLEEPs there! :)

Commenting out the following line:
sleep(response.in.readLong());

Reduced the execution time from 280 secs to 18! :)

Alexander, could you please confirm that this also improves your
results?

Maxim, typically sleep() is not a good idea anywhere. If you really
need to have some delays, wait() is typically better.

But in this particular situation, something is definitely wrong. There
is no need for such severe performance degradation.

Thanks,
--Vladimir

On Fri, May 11, 2007 at 09:07:56AM -0700, Vladimir Sizikov wrote:
> Hi Alexander,
>
> On Fri, May 11, 2007 at 06:25:13PM +0400, Alexander Alexeev wrote:
> > I have tried to run CDC TCK with different comm clients today:
> > DatagramSocketCommClient, MidHttpCommClient and SocketCommClient.
> > Unfortunately I can observe the same performance degradation for all
> > of them. I will try to find the bottle neck.
>
> This is very serious and requires our immediate attention. With
> serious performance degradations we cannot easily swtich to the new
> Agent and communications.
>
> Could you please work with Maxim with as much effort as you can put
> into this problem?
>
> Also, could you please provide some info, description (and possibly
> scripts) on how did you setup the whole thing? I'll probably try to
> look at it as well, and don't want to spend too much time going the
> same path you've already completed.
>
> Thanks,
> --Vladimir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Vladimir, Maxim,

Cool! It's really works for me! Now new agent works the same time as old. And
for both clients: datagram and socket.

Really sleep() in BaseClientExecutionService is implemented through wait() but
I'm curious why this sleep is needed also.

Thanks,
Alexander

Vladimir Sizikov wrote:
> Hi Maxim, Alexander,
>
> Hurray! I was able to find the bottleneck. :)
>
> Take a look at BaseClientExecutionService.exchangeBytes(), you'll
> find a couple of SLEEPs there! :)
>
> Commenting out the following line:
> sleep(response.in.readLong());
>
> Reduced the execution time from 280 secs to 18! :)
>
> Alexander, could you please confirm that this also improves your
> results?
>
> Maxim, typically sleep() is not a good idea anywhere. If you really
> need to have some delays, wait() is typically better.
>
> But in this particular situation, something is definitely wrong. There
> is no need for such severe performance degradation.
>
> Thanks,
> --Vladimir
>
> On Fri, May 11, 2007 at 09:07:56AM -0700, Vladimir Sizikov wrote:
>> Hi Alexander,
>>
>> On Fri, May 11, 2007 at 06:25:13PM +0400, Alexander Alexeev wrote:
>>> I have tried to run CDC TCK with different comm clients today:
>>> DatagramSocketCommClient, MidHttpCommClient and SocketCommClient.
>>> Unfortunately I can observe the same performance degradation for all
>>> of them. I will try to find the bottle neck.
>> This is very serious and requires our immediate attention. With
>> serious performance degradations we cannot easily swtich to the new
>> Agent and communications.
>>
>> Could you please work with Maxim with as much effort as you can put
>> into this problem?
>>
>> Also, could you please provide some info, description (and possibly
>> scripts) on how did you setup the whole thing? I'll probably try to
>> look at it as well, and don't want to spend too much time going the
>> same path you've already completed.
>>
>> Thanks,
>> --Vladimir
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Maxim,

Now I've started review changes in interview for enabling pluggable
communication channel. Below some my comments:

1. exportCommonData() in CdcBaseCommInterview is never called. Therefore
test's run fails due to incorrect script.

2. Does it really need to use static fields for tags? Seems simple
string constant looks more readable. In any case it need to be
consistent - all questions through interview should use strings or
static fields. One more comment - fields should be private as much as
possible.

3. Should be possible to choose http client: MidHTTPCommClient (yes, the
name is rather confusing but in reality currently it used by distributed
test when tcp/ip transport is chosen).

Thanks,
Alexander

Maxim Sokolnikov wrote:
> Alexander,
>
> Thank you for your results. It looks like there is a performance
> problem in DatagramSocketComm(Client|Server).
>
> The difference is that datagram_commClient sends packages one by one
> and expects response from the packet prior sending next packet.
> The datagram connection used in the DatagramAgent implements more
> complicated tcp/ip like protocol.
>
> If in old TCKs the data being sent by
> DatagramSocketComm(Client|Server) was not too large, then now, the class
> loading and sending of the tests results causes that this simple
> problem becomes bottle neck.
>
> I think that the more efficient implementation of the
> DatagramSocketComm(Client|Server) could be implemented.
>
> Today I have run CLDC TCK using generic communication agent with
> SocketComm(Client|Server) and using standard TCK/IP JavaTest agent.
>
> I have run the tests with concurrency 5 using 8 separate concurrent
> agents in both runs.
>
> The generic agent executed the tests for 4:55 and standard agent
> executed the for 4:36.
>
> It shown performance degradation 7% or 2 seconds for each 1000 tests.
>
> I think that the execution framework does not introduce performance
> problems and new scheme can replace the existing execution agents
> after DatagramSocketComm(Client|Server) optimization.
>
>
> Thank you,
> Maxim
>
>
> Alexander Alexeev writes:
> > Hi Maxim,
> >
> > I've submitted yet another issue:
> > https://cqme.dev.java.net/issues/show_bug.cgi?id=140
> >
> > Also I've tested new framework with CDC TCK and found performance degradation:
> > run of api tests get about 73 minutes with new agent in opposite to about 31
> > minutes with old agent.
> >
> > Thanks,
> > Alexander
> >
> > Maxim Sokolnikov wrote:
> > > Alexander,
> > >
> > > Thank you for your results. I am going to fix the problems before end
> > > of this week.
> > >
> > > Thank you,
> > > Maxim
> > >
> > > Alexander Alexeev writes:
> > > > Hi Maxim,
> > > >
> > > > I've started review generic communication execution framework and submitted
> > > > several issues already:
> > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=135
> > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=136
> > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=137
> > > >
> > > > Please review them and provide your comments.
> > > >
> > > > Thanks,
> > > > Alexander
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> > > For additional commands, e-mail: meframework-help@cqme.dev.java.net
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Maxim Sokolnikov

Alexander,

Thank you for your results. I am going to fix the problems before end
of this week.

Thank you,
Maxim

Alexander Alexeev writes:
> Hi Maxim,
>
> I've started review generic communication execution framework and submitted
> several issues already:
> https://cqme.dev.java.net/issues/show_bug.cgi?id=135
> https://cqme.dev.java.net/issues/show_bug.cgi?id=136
> https://cqme.dev.java.net/issues/show_bug.cgi?id=137
>
> Please review them and provide your comments.
>
> Thanks,
> Alexander

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Maxim,

I've submitted yet another issue:
https://cqme.dev.java.net/issues/show_bug.cgi?id=140

Also I've tested new framework with CDC TCK and found performance degradation:
run of api tests get about 73 minutes with new agent in opposite to about 31
minutes with old agent.

Thanks,
Alexander

Maxim Sokolnikov wrote:
> Alexander,
>
> Thank you for your results. I am going to fix the problems before end
> of this week.
>
> Thank you,
> Maxim
>
> Alexander Alexeev writes:
> > Hi Maxim,
> >
> > I've started review generic communication execution framework and submitted
> > several issues already:
> > https://cqme.dev.java.net/issues/show_bug.cgi?id=135
> > https://cqme.dev.java.net/issues/show_bug.cgi?id=136
> > https://cqme.dev.java.net/issues/show_bug.cgi?id=137
> >
> > Please review them and provide your comments.
> >
> > Thanks,
> > Alexander
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Maxim Sokolnikov

Alexander,

Thank you for your results. It looks like there is a performance
problem in DatagramSocketComm(Client|Server).

The difference is that datagram_commClient sends packages one by one
and expects response from the packet prior sending next packet.
The datagram connection used in the DatagramAgent implements more
complicated tcp/ip like protocol.

If in old TCKs the data being sent by
DatagramSocketComm(Client|Server) was not too large, then now, the class
loading and sending of the tests results causes that this simple
problem becomes bottle neck.

I think that the more efficient implementation of the
DatagramSocketComm(Client|Server) could be implemented.

Today I have run CLDC TCK using generic communication agent with
SocketComm(Client|Server) and using standard TCK/IP JavaTest agent.

I have run the tests with concurrency 5 using 8 separate concurrent
agents in both runs.

The generic agent executed the tests for 4:55 and standard agent
executed the for 4:36.

It shown performance degradation 7% or 2 seconds for each 1000 tests.

I think that the execution framework does not introduce performance
problems and new scheme can replace the existing execution agents
after DatagramSocketComm(Client|Server) optimization.

Thank you,
Maxim

Alexander Alexeev writes:
> Hi Maxim,
>
> I've submitted yet another issue:
> https://cqme.dev.java.net/issues/show_bug.cgi?id=140
>
> Also I've tested new framework with CDC TCK and found performance degradation:
> run of api tests get about 73 minutes with new agent in opposite to about 31
> minutes with old agent.
>
> Thanks,
> Alexander
>
> Maxim Sokolnikov wrote:
> > Alexander,
> >
> > Thank you for your results. I am going to fix the problems before end
> > of this week.
> >
> > Thank you,
> > Maxim
> >
> > Alexander Alexeev writes:
> > > Hi Maxim,
> > >
> > > I've started review generic communication execution framework and submitted
> > > several issues already:
> > > https://cqme.dev.java.net/issues/show_bug.cgi?id=135
> > > https://cqme.dev.java.net/issues/show_bug.cgi?id=136
> > > https://cqme.dev.java.net/issues/show_bug.cgi?id=137
> > >
> > > Please review them and provide your comments.
> > >
> > > Thanks,
> > > Alexander
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> > For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Maxim,

I have tried to run CDC TCK with different comm clients today:
DatagramSocketCommClient, MidHttpCommClient and SocketCommClient. Unfortunately
I can observe the same performance degradation for all of them. I will try to
find the bottle neck. And just to be clear: are you running CLDC TCK or CDC TCK?

Thanks,
Alexander

Maxim Sokolnikov wrote:
> Alexander,
>
> Thank you for your results. It looks like there is a performance
> problem in DatagramSocketComm(Client|Server).
>
> The difference is that datagram_commClient sends packages one by one
> and expects response from the packet prior sending next packet.
> The datagram connection used in the DatagramAgent implements more
> complicated tcp/ip like protocol.
>
> If in old TCKs the data being sent by
> DatagramSocketComm(Client|Server) was not too large, then now, the class
> loading and sending of the tests results causes that this simple
> problem becomes bottle neck.
>
> I think that the more efficient implementation of the
> DatagramSocketComm(Client|Server) could be implemented.
>
> Today I have run CLDC TCK using generic communication agent with
> SocketComm(Client|Server) and using standard TCK/IP JavaTest agent.
>
> I have run the tests with concurrency 5 using 8 separate concurrent
> agents in both runs.
>
> The generic agent executed the tests for 4:55 and standard agent
> executed the for 4:36.
>
> It shown performance degradation 7% or 2 seconds for each 1000 tests.
>
> I think that the execution framework does not introduce performance
> problems and new scheme can replace the existing execution agents
> after DatagramSocketComm(Client|Server) optimization.
>
>
> Thank you,
> Maxim
>
>
> Alexander Alexeev writes:
> > Hi Maxim,
> >
> > I've submitted yet another issue:
> > https://cqme.dev.java.net/issues/show_bug.cgi?id=140
> >
> > Also I've tested new framework with CDC TCK and found performance degradation:
> > run of api tests get about 73 minutes with new agent in opposite to about 31
> > minutes with old agent.
> >
> > Thanks,
> > Alexander
> >
> > Maxim Sokolnikov wrote:
> > > Alexander,
> > >
> > > Thank you for your results. I am going to fix the problems before end
> > > of this week.
> > >
> > > Thank you,
> > > Maxim
> > >
> > > Alexander Alexeev writes:
> > > > Hi Maxim,
> > > >
> > > > I've started review generic communication execution framework and submitted
> > > > several issues already:
> > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=135
> > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=136
> > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=137
> > > >
> > > > Please review them and provide your comments.
> > > >
> > > > Thanks,
> > > > Alexander
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> > > For additional commands, e-mail: meframework-help@cqme.dev.java.net
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Maxim Sokolnikov

Alexander,

Alexander Alexeev writes:
> Hi Maxim,
>
> I have tried to run CDC TCK with different comm clients today:
> DatagramSocketCommClient, MidHttpCommClient and SocketCommClient. Unfortunately
> I can observe the same performance degradation for all of them. I will try to
> find the bottle neck. And just to be clear: are you running CLDC TCK or CDC TCK?
>

I run CDC TCK. Can we discuss it by phone today or by Monday?

Thank you,
Maxim

> Thanks,
> Alexander
>
> Maxim Sokolnikov wrote:
> > Alexander,
> >
> > Thank you for your results. It looks like there is a performance
> > problem in DatagramSocketComm(Client|Server).
> >
> > The difference is that datagram_commClient sends packages one by one
> > and expects response from the packet prior sending next packet.
> > The datagram connection used in the DatagramAgent implements more
> > complicated tcp/ip like protocol.
> >
> > If in old TCKs the data being sent by
> > DatagramSocketComm(Client|Server) was not too large, then now, the class
> > loading and sending of the tests results causes that this simple
> > problem becomes bottle neck.
> >
> > I think that the more efficient implementation of the
> > DatagramSocketComm(Client|Server) could be implemented.
> >
> > Today I have run CLDC TCK using generic communication agent with
> > SocketComm(Client|Server) and using standard TCK/IP JavaTest agent.
> >
> > I have run the tests with concurrency 5 using 8 separate concurrent
> > agents in both runs.
> >
> > The generic agent executed the tests for 4:55 and standard agent
> > executed the for 4:36.
> >
> > It shown performance degradation 7% or 2 seconds for each 1000 tests.
> >
> > I think that the execution framework does not introduce performance
> > problems and new scheme can replace the existing execution agents
> > after DatagramSocketComm(Client|Server) optimization.
> >
> >
> > Thank you,
> > Maxim
> >
> >
> > Alexander Alexeev writes:
> > > Hi Maxim,
> > >
> > > I've submitted yet another issue:
> > > https://cqme.dev.java.net/issues/show_bug.cgi?id=140
> > >
> > > Also I've tested new framework with CDC TCK and found performance degradation:
> > > run of api tests get about 73 minutes with new agent in opposite to about 31
> > > minutes with old agent.
> > >
> > > Thanks,
> > > Alexander
> > >
> > > Maxim Sokolnikov wrote:
> > > > Alexander,
> > > >
> > > > Thank you for your results. I am going to fix the problems before end
> > > > of this week.
> > > >
> > > > Thank you,
> > > > Maxim
> > > >
> > > > Alexander Alexeev writes:
> > > > > Hi Maxim,
> > > > >
> > > > > I've started review generic communication execution framework and submitted
> > > > > several issues already:
> > > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=135
> > > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=136
> > > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=137
> > > > >
> > > > > Please review them and provide your comments.
> > > > >
> > > > > Thanks,
> > > > > Alexander
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> > > > For additional commands, e-mail: meframework-help@cqme.dev.java.net
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> > For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Maxim,

OK. I'm out of office already, so let discuss on Monday.

Thanks,
Alexander

Maxim Sokolnikov wrote:
> Alexander,
>
> Alexander Alexeev writes:
> > Hi Maxim,
> >
> > I have tried to run CDC TCK with different comm clients today:
> > DatagramSocketCommClient, MidHttpCommClient and SocketCommClient. Unfortunately
> > I can observe the same performance degradation for all of them. I will try to
> > find the bottle neck. And just to be clear: are you running CLDC TCK or CDC TCK?
> >
>
> I run CDC TCK. Can we discuss it by phone today or by Monday?
>
> Thank you,
> Maxim
>
> > Thanks,
> > Alexander
> >
> > Maxim Sokolnikov wrote:
> > > Alexander,
> > >
> > > Thank you for your results. It looks like there is a performance
> > > problem in DatagramSocketComm(Client|Server).
> > >
> > > The difference is that datagram_commClient sends packages one by one
> > > and expects response from the packet prior sending next packet.
> > > The datagram connection used in the DatagramAgent implements more
> > > complicated tcp/ip like protocol.
> > >
> > > If in old TCKs the data being sent by
> > > DatagramSocketComm(Client|Server) was not too large, then now, the class
> > > loading and sending of the tests results causes that this simple
> > > problem becomes bottle neck.
> > >
> > > I think that the more efficient implementation of the
> > > DatagramSocketComm(Client|Server) could be implemented.
> > >
> > > Today I have run CLDC TCK using generic communication agent with
> > > SocketComm(Client|Server) and using standard TCK/IP JavaTest agent.
> > >
> > > I have run the tests with concurrency 5 using 8 separate concurrent
> > > agents in both runs.
> > >
> > > The generic agent executed the tests for 4:55 and standard agent
> > > executed the for 4:36.
> > >
> > > It shown performance degradation 7% or 2 seconds for each 1000 tests.
> > >
> > > I think that the execution framework does not introduce performance
> > > problems and new scheme can replace the existing execution agents
> > > after DatagramSocketComm(Client|Server) optimization.
> > >
> > >
> > > Thank you,
> > > Maxim
> > >
> > >
> > > Alexander Alexeev writes:
> > > > Hi Maxim,
> > > >
> > > > I've submitted yet another issue:
> > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=140
> > > >
> > > > Also I've tested new framework with CDC TCK and found performance degradation:
> > > > run of api tests get about 73 minutes with new agent in opposite to about 31
> > > > minutes with old agent.
> > > >
> > > > Thanks,
> > > > Alexander
> > > >
> > > > Maxim Sokolnikov wrote:
> > > > > Alexander,
> > > > >
> > > > > Thank you for your results. I am going to fix the problems before end
> > > > > of this week.
> > > > >
> > > > > Thank you,
> > > > > Maxim
> > > > >
> > > > > Alexander Alexeev writes:
> > > > > > Hi Maxim,
> > > > > >
> > > > > > I've started review generic communication execution framework and submitted
> > > > > > several issues already:
> > > > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=135
> > > > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=136
> > > > > > https://cqme.dev.java.net/issues/show_bug.cgi?id=137
> > > > > >
> > > > > > Please review them and provide your comments.
> > > > > >
> > > > > > Thanks,
> > > > > > Alexander
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> > > > > For additional commands, e-mail: meframework-help@cqme.dev.java.net
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> > > For additional commands, e-mail: meframework-help@cqme.dev.java.net
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> > For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net