RE: [Proposal] Switch to Java 7
+1 - used Java 7 for Hyper-V work. Only annoying bit was back porting to 6 for master merge. DL > -Original Message- > From: Hugo Trippaers [mailto:[email protected]] > Sent: 07 January 2014 22:50 > To: [email protected] > Cc: [email protected] > Subject: Re: [Proposal] Switch to Java 7 > > I would be in favor as well. In addition to the already discussed reasons, I > think it would be good to try to get our users to a well maintained version of > Java. From a security point of view 1.6 is not a smart choice any more. > > Upgrading to Jdk 7 could also trigger an upgrade to tomcat 7. Best practice > indicates that t6 should be used with Jdk 16 and T7 with Jdk 17. I didn't > check > yet if t7 is available in our supported distros atm. > > Anyway I would propose to bump the version of CS to 5 when we do this, so > we clearly indicate to our users that something serious has changed. Some of > our users will have to upgrade components outside the CS scope (Jdk) and I > think that warrants a major version bump. > > Cheers, > > Hugo > > Verstuurd vanaf mijn iPad > > > Op 7 jan. 2014 om 23:38 heeft Kelven Yang het > volgende geschreven: > > > > +1 for switching to Java 7 in CloudStack 4.4. > > > > Kelven > > > >> On 1/6/14, 10:27 PM, "Wido den Hollander" wrote: > >> > >> Just to repeat what has been discussed some time ago. > >> > >> All the current Long Term Support distributions have Java 7 available. > >> > >> RHEL6, RHEL7, Ubuntu 12.04, Ubuntu 14.04 (due in April) will all have > >> Java 7 available. > >> > >> I don't see a problem in switching to Java 7 with CloudStack 4.4 or > >> 4.5 > >> > >> Wido > >> > >>> On 01/07/2014 12:18 AM, Kelven Yang wrote: > >>> Java 7 has been around for some time now. I strongly suggest > >>> CloudStack to adopt Java 7 as early as possible, the reason I feel > >>> like to raise the issue is from the some of practicing with the new > >>> DB transaction pattern, as following example shows. The new > >>> Transaction pattern uses anonymous class to beautify the code > >>> structure, but in the mean time, it will introduce a couple runtime > >>> costs > >>> > >>> 1. Anonymous class introduces a ³captured context², information > >>> exchange between the containing context and the anonymous class > >>> implementation context has either to go through with mutable > >>> passed-in parameter or returned result object, in the following > >>> example, without changing basic Transaction framework, I have to > >>> exchange through returned result with an un-typed array. This has a > >>> few implications at run time, basically with each call of the > >>> method, it will generate two objects to the heap. Depends on how > >>> frequently the involved method will be called, it may introduce quite a > burden to java GC process > >>> 2. Anonymous class captured context also means that there will be > >>> more hidden classes be generated, since each appearance of the > >>> anonymous class implementation will have a distance copy of its own > >>> as hidden class, it will generally increase our permanent heap > >>> usage, which is already pretty huge with current CloudStack code base. > >>> > >>> Java 7 has a language level support to address the issues in a > >>> cheaper way that our current DB Transaction code pattern is trying to > solve. > >>> > http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceCl > >>> ose.html. So, time to adopt Java 7? > >>> > >>> public Outcome startVmThroughJobQueue(final > >>> String vmUuid, > >>> final Map params, > >>> final DeploymentPlan planToDeploy) { > >>> > >>> final CallContext context = CallContext.current(); > >>> final User callingUser = context.getCallingUser(); > >>> final Account callingAccount = context.getCallingAccount(); > >>> > >>> final VMInstanceVO vm = _vmDao.findByUuid(vmUuid); > >>> > >>> > >>> Object[] result = Transaction.execute(new > >>> TransactionCallback() { > >>> @Override > >>> public Object[] doInTransaction(TransactionStatus status) { > >>> VmWorkJobVO workJob = null; > >>
RE: [Proposal] Switch to Java 7
+1 for java 1.7 -Original Message- From: Laszlo Hornyak [mailto:[email protected]] Sent: Wednesday, January 8, 2014 4:50 AM To: [email protected] Subject: Re: [Proposal] Switch to Java 7 +1 for java 1.7 and resource blocks, it will help to simplify On Tue, Jan 7, 2014 at 11:50 PM, Hugo Trippaers wrote: > I would be in favor as well. In addition to the already discussed > reasons, I think it would be good to try to get our users to a well > maintained version of Java. From a security point of view 1.6 is not a > smart choice any more. > > Upgrading to Jdk 7 could also trigger an upgrade to tomcat 7. Best > practice indicates that t6 should be used with Jdk 16 and T7 with Jdk > 17. I didn't check yet if t7 is available in our supported distros atm. > > Anyway I would propose to bump the version of CS to 5 when we do this, > so we clearly indicate to our users that something serious has > changed. Some of our users will have to upgrade components outside the > CS scope (Jdk) and I think that warrants a major version bump. > > Cheers, > > Hugo > > Verstuurd vanaf mijn iPad > > > Op 7 jan. 2014 om 23:38 heeft Kelven Yang > > het > volgende geschreven: > > > > +1 for switching to Java 7 in CloudStack 4.4. > > > > Kelven > > > >> On 1/6/14, 10:27 PM, "Wido den Hollander" wrote: > >> > >> Just to repeat what has been discussed some time ago. > >> > >> All the current Long Term Support distributions have Java 7 available. > >> > >> RHEL6, RHEL7, Ubuntu 12.04, Ubuntu 14.04 (due in April) will all > >> have Java 7 available. > >> > >> I don't see a problem in switching to Java 7 with CloudStack 4.4 or > >> 4.5 > >> > >> Wido > >> > >>> On 01/07/2014 12:18 AM, Kelven Yang wrote: > >>> Java 7 has been around for some time now. I strongly suggest > >>> CloudStack to adopt Java 7 as early as possible, the reason I feel > >>> like to raise the issue is from the some of practicing with the > >>> new DB transaction pattern, as following example shows. The new > >>> Transaction pattern uses anonymous class to beautify the code > >>> structure, but in the mean time, > it > >>> will introduce a couple runtime costs > >>> > >>> 1. Anonymous class introduces a ³captured context², information > >>> exchange between the containing context and the anonymous class > >>> implementation context has either to go through with mutable > >>> passed-in parameter or returned result object, in the following > >>> example, without changing basic Transaction framework, I have to > >>> exchange through returned result with an un-typed array. This has > >>> a few implications at run time, basically with each call of the > >>> method, it will generate two objects to the heap. Depends on how > >>> frequently the involved method will be called, it may introduce quite a > >>> burden to java GC process > >>> 2. Anonymous class captured context also means that there will > >>> be more hidden classes be generated, since each appearance of the > anonymous > >>> class implementation will have a distance copy of its own as > >>> hidden class, it will generally increase our permanent heap usage, > >>> which is already pretty huge with current CloudStack code base. > >>> > >>> Java 7 has a language level support to address the issues in a > >>> cheaper way that our current DB Transaction code pattern is trying to > >>> solve. > >>> > http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourc > eCl > >>> ose.html. So, time to adopt Java 7? > >>> > >>> public Outcome startVmThroughJobQueue(final > >>> String vmUuid, > >>> final Map params, > >>> final DeploymentPlan planToDeploy) { > >>> > >>> final CallContext context = CallContext.current(); > >>> final User callingUser = context.getCallingUser(); > >>> final Account callingAccount = > >>> context.getCallingAccount(); > >>> > >>> final VMInstanceVO vm = _vmDao.findByUuid(vmUuid); > >>> > >>> > >>> Object[] result = Transaction.execute(new > >>> TransactionCallback() { > >>> @Override > >>> public Object[] doInTransaction(Tr
Re: [Proposal] Switch to Java 7
+1 for java 1.7 and resource blocks, it will help to simplify
On Tue, Jan 7, 2014 at 11:50 PM, Hugo Trippaers wrote:
> I would be in favor as well. In addition to the already discussed reasons,
> I think it would be good to try to get our users to a well maintained
> version of Java. From a security point of view 1.6 is not a smart choice
> any more.
>
> Upgrading to Jdk 7 could also trigger an upgrade to tomcat 7. Best
> practice indicates that t6 should be used with Jdk 16 and T7 with Jdk 17. I
> didn't check yet if t7 is available in our supported distros atm.
>
> Anyway I would propose to bump the version of CS to 5 when we do this, so
> we clearly indicate to our users that something serious has changed. Some
> of our users will have to upgrade components outside the CS scope (Jdk) and
> I think that warrants a major version bump.
>
> Cheers,
>
> Hugo
>
> Verstuurd vanaf mijn iPad
>
> > Op 7 jan. 2014 om 23:38 heeft Kelven Yang het
> volgende geschreven:
> >
> > +1 for switching to Java 7 in CloudStack 4.4.
> >
> > Kelven
> >
> >> On 1/6/14, 10:27 PM, "Wido den Hollander" wrote:
> >>
> >> Just to repeat what has been discussed some time ago.
> >>
> >> All the current Long Term Support distributions have Java 7 available.
> >>
> >> RHEL6, RHEL7, Ubuntu 12.04, Ubuntu 14.04 (due in April) will all have
> >> Java 7 available.
> >>
> >> I don't see a problem in switching to Java 7 with CloudStack 4.4 or 4.5
> >>
> >> Wido
> >>
> >>> On 01/07/2014 12:18 AM, Kelven Yang wrote:
> >>> Java 7 has been around for some time now. I strongly suggest CloudStack
> >>> to adopt Java 7 as early as possible, the reason I feel like to raise
> >>> the issue is from the some of practicing with the new DB transaction
> >>> pattern, as following example shows. The new Transaction pattern uses
> >>> anonymous class to beautify the code structure, but in the mean time,
> it
> >>> will introduce a couple runtime costs
> >>>
> >>> 1. Anonymous class introduces a ³captured context², information
> >>> exchange between the containing context and the anonymous class
> >>> implementation context has either to go through with mutable passed-in
> >>> parameter or returned result object, in the following example, without
> >>> changing basic Transaction framework, I have to exchange through
> >>> returned result with an un-typed array. This has a few implications at
> >>> run time, basically with each call of the method, it will generate two
> >>> objects to the heap. Depends on how frequently the involved method will
> >>> be called, it may introduce quite a burden to java GC process
> >>> 2. Anonymous class captured context also means that there will be
> >>> more hidden classes be generated, since each appearance of the
> anonymous
> >>> class implementation will have a distance copy of its own as hidden
> >>> class, it will generally increase our permanent heap usage, which is
> >>> already pretty huge with current CloudStack code base.
> >>>
> >>> Java 7 has a language level support to address the issues in a cheaper
> >>> way that our current DB Transaction code pattern is trying to solve.
> >>>
> http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceCl
> >>> ose.html. So, time to adopt Java 7?
> >>>
> >>> public Outcome startVmThroughJobQueue(final String
> >>> vmUuid,
> >>> final Map params,
> >>> final DeploymentPlan planToDeploy) {
> >>>
> >>> final CallContext context = CallContext.current();
> >>> final User callingUser = context.getCallingUser();
> >>> final Account callingAccount = context.getCallingAccount();
> >>>
> >>> final VMInstanceVO vm = _vmDao.findByUuid(vmUuid);
> >>>
> >>>
> >>> Object[] result = Transaction.execute(new
> >>> TransactionCallback() {
> >>> @Override
> >>> public Object[] doInTransaction(TransactionStatus status) {
> >>> VmWorkJobVO workJob = null;
> >>>
> >>>_vmDao.lockRow(vm.getId(), true);
> >>>List pendingWorkJobs =
> >>> _workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance,
> >>> vm.getId(), VmWorkStart.class.getName());
> >>>
> >>>if (pendingWorkJobs.size() > 0) {
> >>>assert (pendingWorkJobs.size() == 1);
> >>>workJob = pendingWorkJobs.get(0);
> >>>} else {
> >>>workJob = new VmWorkJobVO(context.getContextId());
> >>>
> >>>
> >>> workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER);
> >>>workJob.setCmd(VmWorkStart.class.getName());
> >>>
> >>>workJob.setAccountId(callingAccount.getId());
> >>>workJob.setUserId(callingUser.getId());
> >>>workJob.setStep(VmWorkJobVO.Step.Starting);
> >>>workJob.setVmType(vm.getType());
> >>>workJob.setVmInstanceId(vm.getId());
> >>>
> >>> workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId());
> >>>
> >>>// sav
Re: [Proposal] Switch to Java 7
I would be in favor as well. In addition to the already discussed reasons, I
think it would be good to try to get our users to a well maintained version of
Java. From a security point of view 1.6 is not a smart choice any more.
Upgrading to Jdk 7 could also trigger an upgrade to tomcat 7. Best practice
indicates that t6 should be used with Jdk 16 and T7 with Jdk 17. I didn't check
yet if t7 is available in our supported distros atm.
Anyway I would propose to bump the version of CS to 5 when we do this, so we
clearly indicate to our users that something serious has changed. Some of our
users will have to upgrade components outside the CS scope (Jdk) and I think
that warrants a major version bump.
Cheers,
Hugo
Verstuurd vanaf mijn iPad
> Op 7 jan. 2014 om 23:38 heeft Kelven Yang het
> volgende geschreven:
>
> +1 for switching to Java 7 in CloudStack 4.4.
>
> Kelven
>
>> On 1/6/14, 10:27 PM, "Wido den Hollander" wrote:
>>
>> Just to repeat what has been discussed some time ago.
>>
>> All the current Long Term Support distributions have Java 7 available.
>>
>> RHEL6, RHEL7, Ubuntu 12.04, Ubuntu 14.04 (due in April) will all have
>> Java 7 available.
>>
>> I don't see a problem in switching to Java 7 with CloudStack 4.4 or 4.5
>>
>> Wido
>>
>>> On 01/07/2014 12:18 AM, Kelven Yang wrote:
>>> Java 7 has been around for some time now. I strongly suggest CloudStack
>>> to adopt Java 7 as early as possible, the reason I feel like to raise
>>> the issue is from the some of practicing with the new DB transaction
>>> pattern, as following example shows. The new Transaction pattern uses
>>> anonymous class to beautify the code structure, but in the mean time, it
>>> will introduce a couple runtime costs
>>>
>>> 1. Anonymous class introduces a ³captured context², information
>>> exchange between the containing context and the anonymous class
>>> implementation context has either to go through with mutable passed-in
>>> parameter or returned result object, in the following example, without
>>> changing basic Transaction framework, I have to exchange through
>>> returned result with an un-typed array. This has a few implications at
>>> run time, basically with each call of the method, it will generate two
>>> objects to the heap. Depends on how frequently the involved method will
>>> be called, it may introduce quite a burden to java GC process
>>> 2. Anonymous class captured context also means that there will be
>>> more hidden classes be generated, since each appearance of the anonymous
>>> class implementation will have a distance copy of its own as hidden
>>> class, it will generally increase our permanent heap usage, which is
>>> already pretty huge with current CloudStack code base.
>>>
>>> Java 7 has a language level support to address the issues in a cheaper
>>> way that our current DB Transaction code pattern is trying to solve.
>>> http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceCl
>>> ose.html. So, time to adopt Java 7?
>>>
>>> public Outcome startVmThroughJobQueue(final String
>>> vmUuid,
>>> final Map params,
>>> final DeploymentPlan planToDeploy) {
>>>
>>> final CallContext context = CallContext.current();
>>> final User callingUser = context.getCallingUser();
>>> final Account callingAccount = context.getCallingAccount();
>>>
>>> final VMInstanceVO vm = _vmDao.findByUuid(vmUuid);
>>>
>>>
>>> Object[] result = Transaction.execute(new
>>> TransactionCallback() {
>>> @Override
>>> public Object[] doInTransaction(TransactionStatus status) {
>>> VmWorkJobVO workJob = null;
>>>
>>>_vmDao.lockRow(vm.getId(), true);
>>>List pendingWorkJobs =
>>> _workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance,
>>> vm.getId(), VmWorkStart.class.getName());
>>>
>>>if (pendingWorkJobs.size() > 0) {
>>>assert (pendingWorkJobs.size() == 1);
>>>workJob = pendingWorkJobs.get(0);
>>>} else {
>>>workJob = new VmWorkJobVO(context.getContextId());
>>>
>>>
>>> workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER);
>>>workJob.setCmd(VmWorkStart.class.getName());
>>>
>>>workJob.setAccountId(callingAccount.getId());
>>>workJob.setUserId(callingUser.getId());
>>>workJob.setStep(VmWorkJobVO.Step.Starting);
>>>workJob.setVmType(vm.getType());
>>>workJob.setVmInstanceId(vm.getId());
>>>
>>> workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId());
>>>
>>>// save work context info (there are some duplications)
>>> VmWorkStart workInfo = new
>>> VmWorkStart(callingUser.getId(), callingAccount.getId(), vm.getId(),
>>> VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER);
>>>workInfo.setPlan(planToDeploy);
>>>workInfo.se
Re: [Proposal] Switch to Java 7
+1 for switching to Java 7 in CloudStack 4.4.
Kelven
On 1/6/14, 10:27 PM, "Wido den Hollander" wrote:
>Just to repeat what has been discussed some time ago.
>
>All the current Long Term Support distributions have Java 7 available.
>
>RHEL6, RHEL7, Ubuntu 12.04, Ubuntu 14.04 (due in April) will all have
>Java 7 available.
>
>I don't see a problem in switching to Java 7 with CloudStack 4.4 or 4.5
>
>Wido
>
>On 01/07/2014 12:18 AM, Kelven Yang wrote:
>> Java 7 has been around for some time now. I strongly suggest CloudStack
>>to adopt Java 7 as early as possible, the reason I feel like to raise
>>the issue is from the some of practicing with the new DB transaction
>>pattern, as following example shows. The new Transaction pattern uses
>>anonymous class to beautify the code structure, but in the mean time, it
>>will introduce a couple runtime costs
>>
>>1. Anonymous class introduces a ³captured context², information
>>exchange between the containing context and the anonymous class
>>implementation context has either to go through with mutable passed-in
>>parameter or returned result object, in the following example, without
>>changing basic Transaction framework, I have to exchange through
>>returned result with an un-typed array. This has a few implications at
>>run time, basically with each call of the method, it will generate two
>>objects to the heap. Depends on how frequently the involved method will
>>be called, it may introduce quite a burden to java GC process
>>2. Anonymous class captured context also means that there will be
>>more hidden classes be generated, since each appearance of the anonymous
>>class implementation will have a distance copy of its own as hidden
>>class, it will generally increase our permanent heap usage, which is
>>already pretty huge with current CloudStack code base.
>>
>> Java 7 has a language level support to address the issues in a cheaper
>>way that our current DB Transaction code pattern is trying to solve.
>>http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceCl
>>ose.html. So, time to adopt Java 7?
>>
>> public Outcome startVmThroughJobQueue(final String
>>vmUuid,
>> final Map params,
>> final DeploymentPlan planToDeploy) {
>>
>> final CallContext context = CallContext.current();
>> final User callingUser = context.getCallingUser();
>> final Account callingAccount = context.getCallingAccount();
>>
>> final VMInstanceVO vm = _vmDao.findByUuid(vmUuid);
>>
>>
>> Object[] result = Transaction.execute(new
>>TransactionCallback() {
>> @Override
>> public Object[] doInTransaction(TransactionStatus status) {
>> VmWorkJobVO workJob = null;
>>
>> _vmDao.lockRow(vm.getId(), true);
>> List pendingWorkJobs =
>>_workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance,
>> vm.getId(), VmWorkStart.class.getName());
>>
>> if (pendingWorkJobs.size() > 0) {
>> assert (pendingWorkJobs.size() == 1);
>> workJob = pendingWorkJobs.get(0);
>> } else {
>> workJob = new VmWorkJobVO(context.getContextId());
>>
>>
>>workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER);
>> workJob.setCmd(VmWorkStart.class.getName());
>>
>> workJob.setAccountId(callingAccount.getId());
>> workJob.setUserId(callingUser.getId());
>> workJob.setStep(VmWorkJobVO.Step.Starting);
>> workJob.setVmType(vm.getType());
>> workJob.setVmInstanceId(vm.getId());
>>
>>workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId());
>>
>> // save work context info (there are some duplications)
>> VmWorkStart workInfo = new
>>VmWorkStart(callingUser.getId(), callingAccount.getId(), vm.getId(),
>>VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER);
>> workInfo.setPlan(planToDeploy);
>> workInfo.setParams(params);
>>
>>workJob.setCmdInfo(VmWorkSerializer.serialize(workInfo));
>>
>> _jobMgr.submitAsyncJob(workJob,
>>VmWorkConstants.VM_WORK_QUEUE, vm.getId());
>> }
>>
>> return new Object[] {workJob, new
>>Long(workJob.getId())};
>> }
>> });
>>
>> final long jobId = (Long)result[1];
>>
>>AsyncJobExecutionContext.getCurrentExecutionContext().joinJob(jobId);
>>
>> return new VmStateSyncOutcome((VmWorkJobVO)result[0],
>> VirtualMachine.PowerState.PowerOn, vm.getId(), null);
>> }
>>
>>
>> Kelven
>>
Re: [Proposal] Switch to Java 7
Just to repeat what has been discussed some time ago.
All the current Long Term Support distributions have Java 7 available.
RHEL6, RHEL7, Ubuntu 12.04, Ubuntu 14.04 (due in April) will all have
Java 7 available.
I don't see a problem in switching to Java 7 with CloudStack 4.4 or 4.5
Wido
On 01/07/2014 12:18 AM, Kelven Yang wrote:
Java 7 has been around for some time now. I strongly suggest CloudStack to
adopt Java 7 as early as possible, the reason I feel like to raise the issue is
from the some of practicing with the new DB transaction pattern, as following
example shows. The new Transaction pattern uses anonymous class to beautify
the code structure, but in the mean time, it will introduce a couple runtime
costs
1. Anonymous class introduces a “captured context”, information exchange
between the containing context and the anonymous class implementation context
has either to go through with mutable passed-in parameter or returned result
object, in the following example, without changing basic Transaction framework,
I have to exchange through returned result with an un-typed array. This has a
few implications at run time, basically with each call of the method, it will
generate two objects to the heap. Depends on how frequently the involved method
will be called, it may introduce quite a burden to java GC process
2. Anonymous class captured context also means that there will be more
hidden classes be generated, since each appearance of the anonymous class
implementation will have a distance copy of its own as hidden class, it will
generally increase our permanent heap usage, which is already pretty huge with
current CloudStack code base.
Java 7 has a language level support to address the issues in a cheaper way that
our current DB Transaction code pattern is trying to solve.
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html.
So, time to adopt Java 7?
public Outcome startVmThroughJobQueue(final String vmUuid,
final Map params,
final DeploymentPlan planToDeploy) {
final CallContext context = CallContext.current();
final User callingUser = context.getCallingUser();
final Account callingAccount = context.getCallingAccount();
final VMInstanceVO vm = _vmDao.findByUuid(vmUuid);
Object[] result = Transaction.execute(new
TransactionCallback() {
@Override
public Object[] doInTransaction(TransactionStatus status) {
VmWorkJobVO workJob = null;
_vmDao.lockRow(vm.getId(), true);
List pendingWorkJobs =
_workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance,
vm.getId(), VmWorkStart.class.getName());
if (pendingWorkJobs.size() > 0) {
assert (pendingWorkJobs.size() == 1);
workJob = pendingWorkJobs.get(0);
} else {
workJob = new VmWorkJobVO(context.getContextId());
workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER);
workJob.setCmd(VmWorkStart.class.getName());
workJob.setAccountId(callingAccount.getId());
workJob.setUserId(callingUser.getId());
workJob.setStep(VmWorkJobVO.Step.Starting);
workJob.setVmType(vm.getType());
workJob.setVmInstanceId(vm.getId());
workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId());
// save work context info (there are some duplications)
VmWorkStart workInfo = new
VmWorkStart(callingUser.getId(), callingAccount.getId(), vm.getId(),
VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER);
workInfo.setPlan(planToDeploy);
workInfo.setParams(params);
workJob.setCmdInfo(VmWorkSerializer.serialize(workInfo));
_jobMgr.submitAsyncJob(workJob,
VmWorkConstants.VM_WORK_QUEUE, vm.getId());
}
return new Object[] {workJob, new Long(workJob.getId())};
}
});
final long jobId = (Long)result[1];
AsyncJobExecutionContext.getCurrentExecutionContext().joinJob(jobId);
return new VmStateSyncOutcome((VmWorkJobVO)result[0],
VirtualMachine.PowerState.PowerOn, vm.getId(), null);
}
Kelven
Re: [Proposal] Switch to Java 7
Java 7 is preferred for Apache Hadoop but not required http://wiki.apache.org/hadoop/HadoopJavaVersions (I was looking to see if other OSS projects had migrated) -- Chiradeep > On Jan 6, 2014, at 6:16 PM, "Ryan Lei" wrote: > > There was yet another similar discussion a half-year ago: > http://markmail.org/thread/ap6v46r3mdsgdszp > > --- > Yu-Heng (Ryan) Lei, Associate Researcher > Cloud Computing Dept, Chunghwa Telecom Labs > [email protected] or [email protected] > > > > On Tue, Jan 7, 2014 at 7:34 AM, Chiradeep Vittal < > [email protected]> wrote: > >> Yes, there was another discussion here: >> http://markmail.org/thread/uf6bxab6u4z4fmrp >> >> >> >>> On 1/6/14 3:18 PM, "Kelven Yang" wrote: >>> >>> Java 7 has been around for some time now. I strongly suggest CloudStack >>> to adopt Java 7 as early as possible, the reason I feel like to raise the >>> issue is from the some of practicing with the new DB transaction pattern, >>> as following example shows. The new Transaction pattern uses anonymous >>> class to beautify the code structure, but in the mean time, it will >>> introduce a couple runtime costs >>> >>> 1. Anonymous class introduces a ³captured context², information >>> exchange between the containing context and the anonymous class >>> implementation context has either to go through with mutable passed-in >>> parameter or returned result object, in the following example, without >>> changing basic Transaction framework, I have to exchange through returned >>> result with an un-typed array. This has a few implications at run time, >>> basically with each call of the method, it will generate two objects to >>> the heap. Depends on how frequently the involved method will be called, >>> it may introduce quite a burden to java GC process >>> 2. Anonymous class captured context also means that there will be more >>> hidden classes be generated, since each appearance of the anonymous class >>> implementation will have a distance copy of its own as hidden class, it >>> will generally increase our permanent heap usage, which is already pretty >>> huge with current CloudStack code base. >>> >>> Java 7 has a language level support to address the issues in a cheaper >>> way that our current DB Transaction code pattern is trying to solve. >> http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClo >>> se.html. So, time to adopt Java 7? >>> >>> public Outcome startVmThroughJobQueue(final String >>> vmUuid, >>> final Map params, >>> final DeploymentPlan planToDeploy) { >>> >>> final CallContext context = CallContext.current(); >>> final User callingUser = context.getCallingUser(); >>> final Account callingAccount = context.getCallingAccount(); >>> >>> final VMInstanceVO vm = _vmDao.findByUuid(vmUuid); >>> >>> >>> Object[] result = Transaction.execute(new >>> TransactionCallback() { >>> @Override >>> public Object[] doInTransaction(TransactionStatus status) { >>> VmWorkJobVO workJob = null; >>> >>> _vmDao.lockRow(vm.getId(), true); >>> List pendingWorkJobs = >>> _workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance, >>> vm.getId(), VmWorkStart.class.getName()); >>> >>> if (pendingWorkJobs.size() > 0) { >>> assert (pendingWorkJobs.size() == 1); >>> workJob = pendingWorkJobs.get(0); >>> } else { >>> workJob = new VmWorkJobVO(context.getContextId()); >>> >>> >>> workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER); >>> workJob.setCmd(VmWorkStart.class.getName()); >>> >>> workJob.setAccountId(callingAccount.getId()); >>> workJob.setUserId(callingUser.getId()); >>> workJob.setStep(VmWorkJobVO.Step.Starting); >>> workJob.setVmType(vm.getType()); >>> workJob.setVmInstanceId(vm.getId()); >>> >>> workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId()); >>> >>> // save work context info (there are some duplications) >>> VmWorkStart workInfo = new >>> VmWorkStart(callingUser.getId(), callingAccount.getId(), vm.getId(), >>> VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER); >>> workInfo.setPlan(planToDeploy); >>> workInfo.setParams(params); >>> workJob.setCmdInfo(VmWorkSerializer.serialize(workInfo)); >>> >>> _jobMgr.submitAsyncJob(workJob, >>> VmWorkConstants.VM_WORK_QUEUE, vm.getId()); >>> } >>> >>> return new Object[] {workJob, new Long(workJob.getId())}; >>> } >>> }); >>> >>> final long jobId = (Long)result[1]; >>> AsyncJobExecutionContext.getCurrentExecutionContext().joinJob(jobId); >>> >>> return new VmStateSyncOutcome((VmWorkJobVO)result[0], >>> VirtualMachine.PowerState.PowerOn, vm.getId(), null)
Re: [Proposal] Switch to Java 7
There was yet another similar discussion a half-year ago: http://markmail.org/thread/ap6v46r3mdsgdszp --- Yu-Heng (Ryan) Lei, Associate Researcher Cloud Computing Dept, Chunghwa Telecom Labs [email protected] or [email protected] On Tue, Jan 7, 2014 at 7:34 AM, Chiradeep Vittal < [email protected]> wrote: > Yes, there was another discussion here: > http://markmail.org/thread/uf6bxab6u4z4fmrp > > > > On 1/6/14 3:18 PM, "Kelven Yang" wrote: > > >Java 7 has been around for some time now. I strongly suggest CloudStack > >to adopt Java 7 as early as possible, the reason I feel like to raise the > >issue is from the some of practicing with the new DB transaction pattern, > >as following example shows. The new Transaction pattern uses anonymous > >class to beautify the code structure, but in the mean time, it will > >introduce a couple runtime costs > > > > 1. Anonymous class introduces a ³captured context², information > >exchange between the containing context and the anonymous class > >implementation context has either to go through with mutable passed-in > >parameter or returned result object, in the following example, without > >changing basic Transaction framework, I have to exchange through returned > >result with an un-typed array. This has a few implications at run time, > >basically with each call of the method, it will generate two objects to > >the heap. Depends on how frequently the involved method will be called, > >it may introduce quite a burden to java GC process > > 2. Anonymous class captured context also means that there will be more > >hidden classes be generated, since each appearance of the anonymous class > >implementation will have a distance copy of its own as hidden class, it > >will generally increase our permanent heap usage, which is already pretty > >huge with current CloudStack code base. > > > >Java 7 has a language level support to address the issues in a cheaper > >way that our current DB Transaction code pattern is trying to solve. > > > http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClo > >se.html. So, time to adopt Java 7? > > > >public Outcome startVmThroughJobQueue(final String > >vmUuid, > >final Map params, > >final DeploymentPlan planToDeploy) { > > > >final CallContext context = CallContext.current(); > >final User callingUser = context.getCallingUser(); > >final Account callingAccount = context.getCallingAccount(); > > > >final VMInstanceVO vm = _vmDao.findByUuid(vmUuid); > > > > > >Object[] result = Transaction.execute(new > >TransactionCallback() { > >@Override > >public Object[] doInTransaction(TransactionStatus status) { > >VmWorkJobVO workJob = null; > > > > _vmDao.lockRow(vm.getId(), true); > > List pendingWorkJobs = > >_workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance, > >vm.getId(), VmWorkStart.class.getName()); > > > > if (pendingWorkJobs.size() > 0) { > > assert (pendingWorkJobs.size() == 1); > > workJob = pendingWorkJobs.get(0); > > } else { > > workJob = new VmWorkJobVO(context.getContextId()); > > > > > >workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER); > > workJob.setCmd(VmWorkStart.class.getName()); > > > > workJob.setAccountId(callingAccount.getId()); > > workJob.setUserId(callingUser.getId()); > > workJob.setStep(VmWorkJobVO.Step.Starting); > > workJob.setVmType(vm.getType()); > > workJob.setVmInstanceId(vm.getId()); > > > >workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId()); > > > > // save work context info (there are some duplications) > >VmWorkStart workInfo = new > >VmWorkStart(callingUser.getId(), callingAccount.getId(), vm.getId(), > >VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER); > > workInfo.setPlan(planToDeploy); > > workInfo.setParams(params); > > workJob.setCmdInfo(VmWorkSerializer.serialize(workInfo)); > > > >_jobMgr.submitAsyncJob(workJob, > >VmWorkConstants.VM_WORK_QUEUE, vm.getId()); > >} > > > >return new Object[] {workJob, new Long(workJob.getId())}; > >} > >}); > > > >final long jobId = (Long)result[1]; > >AsyncJobExecutionContext.getCurrentExecutionContext().joinJob(jobId); > > > >return new VmStateSyncOutcome((VmWorkJobVO)result[0], > >VirtualMachine.PowerState.PowerOn, vm.getId(), null); > >} > > > > > >Kelven > >
Re: [Proposal] Switch to Java 7
Yes, it is for the same reason, to management resource leaking in a better
way. Java 7 finally has added this long-waited language feature. I’ve been
using JRE 7 with CloudStack for a while and didn’t see any alerted issues.
Kelven
On 1/6/14, 3:34 PM, "Chiradeep Vittal" wrote:
>Yes, there was another discussion here:
>http://markmail.org/thread/uf6bxab6u4z4fmrp
>
>
>
>On 1/6/14 3:18 PM, "Kelven Yang" wrote:
>
>>Java 7 has been around for some time now. I strongly suggest CloudStack
>>to adopt Java 7 as early as possible, the reason I feel like to raise the
>>issue is from the some of practicing with the new DB transaction pattern,
>>as following example shows. The new Transaction pattern uses anonymous
>>class to beautify the code structure, but in the mean time, it will
>>introduce a couple runtime costs
>>
>> 1. Anonymous class introduces a ³captured context², information
>>exchange between the containing context and the anonymous class
>>implementation context has either to go through with mutable passed-in
>>parameter or returned result object, in the following example, without
>>changing basic Transaction framework, I have to exchange through returned
>>result with an un-typed array. This has a few implications at run time,
>>basically with each call of the method, it will generate two objects to
>>the heap. Depends on how frequently the involved method will be called,
>>it may introduce quite a burden to java GC process
>> 2. Anonymous class captured context also means that there will be more
>>hidden classes be generated, since each appearance of the anonymous class
>>implementation will have a distance copy of its own as hidden class, it
>>will generally increase our permanent heap usage, which is already pretty
>>huge with current CloudStack code base.
>>
>>Java 7 has a language level support to address the issues in a cheaper
>>way that our current DB Transaction code pattern is trying to solve.
>>http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceCl
>>o
>>se.html. So, time to adopt Java 7?
>>
>>public Outcome startVmThroughJobQueue(final String
>>vmUuid,
>>final Map params,
>>final DeploymentPlan planToDeploy) {
>>
>>final CallContext context = CallContext.current();
>>final User callingUser = context.getCallingUser();
>>final Account callingAccount = context.getCallingAccount();
>>
>>final VMInstanceVO vm = _vmDao.findByUuid(vmUuid);
>>
>>
>>Object[] result = Transaction.execute(new
>>TransactionCallback() {
>>@Override
>>public Object[] doInTransaction(TransactionStatus status) {
>>VmWorkJobVO workJob = null;
>>
>> _vmDao.lockRow(vm.getId(), true);
>> List pendingWorkJobs =
>>_workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance,
>>vm.getId(), VmWorkStart.class.getName());
>>
>> if (pendingWorkJobs.size() > 0) {
>> assert (pendingWorkJobs.size() == 1);
>> workJob = pendingWorkJobs.get(0);
>> } else {
>> workJob = new VmWorkJobVO(context.getContextId());
>>
>>
>>workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER);
>> workJob.setCmd(VmWorkStart.class.getName());
>>
>> workJob.setAccountId(callingAccount.getId());
>> workJob.setUserId(callingUser.getId());
>> workJob.setStep(VmWorkJobVO.Step.Starting);
>> workJob.setVmType(vm.getType());
>> workJob.setVmInstanceId(vm.getId());
>>
>>workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId());
>>
>> // save work context info (there are some duplications)
>>VmWorkStart workInfo = new
>>VmWorkStart(callingUser.getId(), callingAccount.getId(), vm.getId(),
>>VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER);
>> workInfo.setPlan(planToDeploy);
>> workInfo.setParams(params);
>> workJob.setCmdInfo(VmWorkSerializer.serialize(workInfo));
>>
>>_jobMgr.submitAsyncJob(workJob,
>>VmWorkConstants.VM_WORK_QUEUE, vm.getId());
>>}
>>
>>return new Object[] {workJob, new Long(workJob.getId())};
>>}
>>});
>>
>>final long jobId = (Long)result[1];
>>AsyncJobExecutionContext.getCurrentExecutionContext().joinJob(jobId);
>>
>>return new VmStateSyncOutcome((VmWorkJobVO)result[0],
>>VirtualMachine.PowerState.PowerOn, vm.getId(), null);
>>}
>>
>>
>>Kelven
>
Re: [Proposal] Switch to Java 7
Yes, there was another discussion here:
http://markmail.org/thread/uf6bxab6u4z4fmrp
On 1/6/14 3:18 PM, "Kelven Yang" wrote:
>Java 7 has been around for some time now. I strongly suggest CloudStack
>to adopt Java 7 as early as possible, the reason I feel like to raise the
>issue is from the some of practicing with the new DB transaction pattern,
>as following example shows. The new Transaction pattern uses anonymous
>class to beautify the code structure, but in the mean time, it will
>introduce a couple runtime costs
>
> 1. Anonymous class introduces a ³captured context², information
>exchange between the containing context and the anonymous class
>implementation context has either to go through with mutable passed-in
>parameter or returned result object, in the following example, without
>changing basic Transaction framework, I have to exchange through returned
>result with an un-typed array. This has a few implications at run time,
>basically with each call of the method, it will generate two objects to
>the heap. Depends on how frequently the involved method will be called,
>it may introduce quite a burden to java GC process
> 2. Anonymous class captured context also means that there will be more
>hidden classes be generated, since each appearance of the anonymous class
>implementation will have a distance copy of its own as hidden class, it
>will generally increase our permanent heap usage, which is already pretty
>huge with current CloudStack code base.
>
>Java 7 has a language level support to address the issues in a cheaper
>way that our current DB Transaction code pattern is trying to solve.
>http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClo
>se.html. So, time to adopt Java 7?
>
>public Outcome startVmThroughJobQueue(final String
>vmUuid,
>final Map params,
>final DeploymentPlan planToDeploy) {
>
>final CallContext context = CallContext.current();
>final User callingUser = context.getCallingUser();
>final Account callingAccount = context.getCallingAccount();
>
>final VMInstanceVO vm = _vmDao.findByUuid(vmUuid);
>
>
>Object[] result = Transaction.execute(new
>TransactionCallback() {
>@Override
>public Object[] doInTransaction(TransactionStatus status) {
>VmWorkJobVO workJob = null;
>
> _vmDao.lockRow(vm.getId(), true);
> List pendingWorkJobs =
>_workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance,
>vm.getId(), VmWorkStart.class.getName());
>
> if (pendingWorkJobs.size() > 0) {
> assert (pendingWorkJobs.size() == 1);
> workJob = pendingWorkJobs.get(0);
> } else {
> workJob = new VmWorkJobVO(context.getContextId());
>
>
>workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER);
> workJob.setCmd(VmWorkStart.class.getName());
>
> workJob.setAccountId(callingAccount.getId());
> workJob.setUserId(callingUser.getId());
> workJob.setStep(VmWorkJobVO.Step.Starting);
> workJob.setVmType(vm.getType());
> workJob.setVmInstanceId(vm.getId());
>
>workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId());
>
> // save work context info (there are some duplications)
>VmWorkStart workInfo = new
>VmWorkStart(callingUser.getId(), callingAccount.getId(), vm.getId(),
>VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER);
> workInfo.setPlan(planToDeploy);
> workInfo.setParams(params);
> workJob.setCmdInfo(VmWorkSerializer.serialize(workInfo));
>
>_jobMgr.submitAsyncJob(workJob,
>VmWorkConstants.VM_WORK_QUEUE, vm.getId());
>}
>
>return new Object[] {workJob, new Long(workJob.getId())};
>}
>});
>
>final long jobId = (Long)result[1];
>AsyncJobExecutionContext.getCurrentExecutionContext().joinJob(jobId);
>
>return new VmStateSyncOutcome((VmWorkJobVO)result[0],
>VirtualMachine.PowerState.PowerOn, vm.getId(), null);
>}
>
>
>Kelven
[Proposal] Switch to Java 7
Java 7 has been around for some time now. I strongly suggest CloudStack to
adopt Java 7 as early as possible, the reason I feel like to raise the issue is
from the some of practicing with the new DB transaction pattern, as following
example shows. The new Transaction pattern uses anonymous class to beautify
the code structure, but in the mean time, it will introduce a couple runtime
costs
1. Anonymous class introduces a “captured context”, information exchange
between the containing context and the anonymous class implementation context
has either to go through with mutable passed-in parameter or returned result
object, in the following example, without changing basic Transaction framework,
I have to exchange through returned result with an un-typed array. This has a
few implications at run time, basically with each call of the method, it will
generate two objects to the heap. Depends on how frequently the involved method
will be called, it may introduce quite a burden to java GC process
2. Anonymous class captured context also means that there will be more
hidden classes be generated, since each appearance of the anonymous class
implementation will have a distance copy of its own as hidden class, it will
generally increase our permanent heap usage, which is already pretty huge with
current CloudStack code base.
Java 7 has a language level support to address the issues in a cheaper way that
our current DB Transaction code pattern is trying to solve.
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html.
So, time to adopt Java 7?
public Outcome startVmThroughJobQueue(final String vmUuid,
final Map params,
final DeploymentPlan planToDeploy) {
final CallContext context = CallContext.current();
final User callingUser = context.getCallingUser();
final Account callingAccount = context.getCallingAccount();
final VMInstanceVO vm = _vmDao.findByUuid(vmUuid);
Object[] result = Transaction.execute(new
TransactionCallback() {
@Override
public Object[] doInTransaction(TransactionStatus status) {
VmWorkJobVO workJob = null;
_vmDao.lockRow(vm.getId(), true);
List pendingWorkJobs =
_workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance,
vm.getId(), VmWorkStart.class.getName());
if (pendingWorkJobs.size() > 0) {
assert (pendingWorkJobs.size() == 1);
workJob = pendingWorkJobs.get(0);
} else {
workJob = new VmWorkJobVO(context.getContextId());
workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER);
workJob.setCmd(VmWorkStart.class.getName());
workJob.setAccountId(callingAccount.getId());
workJob.setUserId(callingUser.getId());
workJob.setStep(VmWorkJobVO.Step.Starting);
workJob.setVmType(vm.getType());
workJob.setVmInstanceId(vm.getId());
workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId());
// save work context info (there are some duplications)
VmWorkStart workInfo = new VmWorkStart(callingUser.getId(),
callingAccount.getId(), vm.getId(),
VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER);
workInfo.setPlan(planToDeploy);
workInfo.setParams(params);
workJob.setCmdInfo(VmWorkSerializer.serialize(workInfo));
_jobMgr.submitAsyncJob(workJob,
VmWorkConstants.VM_WORK_QUEUE, vm.getId());
}
return new Object[] {workJob, new Long(workJob.getId())};
}
});
final long jobId = (Long)result[1];
AsyncJobExecutionContext.getCurrentExecutionContext().joinJob(jobId);
return new VmStateSyncOutcome((VmWorkJobVO)result[0],
VirtualMachine.PowerState.PowerOn, vm.getId(), null);
}
Kelven
