[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1710:
--------------------------------
As discussed on JGRP-1507: FRAG\{2\} cannot be moved over the transport as retransmission of large messages with 1 fragment missing would cause retransmission of the entire message (all fragments).
Therefore, the current strategy is to move large data from the header into the message's buffer and - if needed - add a second FRAG\{2\} directly over the transport. This second fragmentation protocol would typically not have to do any work, as fragmentation is done by the first fragmentation protocol. The only case where work would need to be done is when large data are added by a protocol, e.g. view and digest by {{INSTALL_MERGE_VIEW in GMS}}.
The advantage of moving large data into the body of a message is that FRAG2.down() can do a cheap {{Message.getLength()}}, compared to a more costly {{Message.size()}} by {{FRAG.down(){{.
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
> Key: JGRP-1710
> URL: https://issues.jboss.org/browse/JGRP-1710
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-1569) Not possible to reload server when JTS transactions are activated
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------
tom.jenkinson(a)redhat.com changed the Status of [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] from NEW to POST
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
> Key: WFLY-1569
> URL: https://issues.jboss.org/browse/WFLY-1569
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
> - <jts/> tag under transactions subsystem
> - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
> at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)
> at org.jacorb.poa.POA.set_servant(POA.java:1979)
> at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)
> ... 5 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-1569) Not possible to reload server when JTS transactions are activated
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------
tom.jenkinson(a)redhat.com made a comment on [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379]
https://github.com/jbossas/jboss-eap/pull/478
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
> Key: WFLY-1569
> URL: https://issues.jboss.org/browse/WFLY-1569
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
> - <jts/> tag under transactions subsystem
> - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
> at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)
> at org.jacorb.poa.POA.set_servant(POA.java:1979)
> at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)
> ... 5 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1507) MFC2: multicast flow control
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1507?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1507 at 10/1/13 6:54 AM:
---------------------------------------------------------
h3. Fragmentation and flow control
It would be nice if we could move FRAG / FRAG2 over the transport so that fragmentation happens _just before sending the message_. This would also solve https://issues.jboss.org/browse/JGRP-1710.
The problem here is that a very large message might overwhelm flow control: if we allow it to pass, FRAG will generate a high number of fragments out of which many might get discarded due to buffer overflow...
Downside: if we have a large message P:5 and FRAG2 generates 100 fragments, if at least 1 fragment is lost, the receiver will ask P to retransmit message 5, resulting in re-sending of P:5 and - due to fragmentation - sending of another 100 fragments.
So, in the worst case, losing 1 fragments causes the resending of 100 fragments. Not a good idea...
was (Author: belaban):
h3. Fragmentation and flow control
It would be nice if we could move FRAG / FRAG2 over the transport so that fragmentation happens _just before sending the message_. This would also solve https://issues.jboss.org/browse/JGRP-1710.
The problem here is that a very large message might overwhelm flow control: if we allow it to pass, FRAG will generate a high number of fragments out of which many might get discarded due to buffer overflow...
> MFC2: multicast flow control
> ----------------------------
>
> Key: JGRP-1507
> URL: https://issues.jboss.org/browse/JGRP-1507
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: Design.pdf
>
>
> The current flow control protocol (MFC) is slowing things down when we have high traffic in multicast networks (UDP based stack), especially when ethernet flow control (802.3) is disabled.
> One reason is that the number of credits (similar to the window size in TCP) is static, and doesn't change. E.g. it doesn't increase when there's no loss and doesn't shrink when there is loss.
> (This will be addressed by a different JIRA later)
> Another reason is that sender credits are currently only used up when *sending* messages, but not when *receiving* messages. Thus, if we have 50MB of credits, a sender A can send 50MB until A blocks. However, when it receives 20MB of traffic from B while it sends the 50MB, it doesn't take the 20MBs into account.
> Therefore, a receiver S can be overwhelmed by receiving both A's and B's traffic (the switch might even start discarding messages before they reach S).
> The change from MFC to MFC2 is that a sender only maintains 1 'credits' counter (number of bytes): whenever it sends a message, it decrements credits. Whenever it receives traffic from someone else, it also decrements credits. When credits is 0, the sender blocks (asking for more credits). When credits drops below a certain threshold, it multicasts 1/N of the max credits (N = number of cluster members). (TBD: perhaps it should mcast a fixed number, independent of the cluster size).
> The advantage of this scheme is that a sender blocks sooner, and not when it's too late (congestion).
> Example:
> - credits = 100MB
> - Concurrently: A sends 50MB, B sends 30MB and C sends 60MB
> - At time T1, A has sent 20MB, and we've already received 10MB from B and 20 from C, credits is now 50MB
> - At time T2, A sent another 20MB, and received 20MB from C. credits is now 10MB, and A multicasts 35MB (rounded)
> - At T3, A receives another 10MB from B, credits=0
> - At T4, A blocks trying to send its remaining 10MBs, as credits = 0
> - At T5, A receives its 35MB of credits and sends its remaining 10MB, and also receives 20MB from C, and the remaining 10MB from B. credits is now -5 and A would block sending more credits
> - At T6, A multicasts 35MBs of credits
> - At T7, A receives 35MB of credits from B and C, credits= ca 65MB
> - At T8, A receives its own 35MBs of credits, credits=~100MB
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1507) MFC2: multicast flow control
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1507?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1507:
--------------------------------
h3. Fragmentation and flow control
It would be nice if we could move FRAG / FRAG2 over the transport so that fragmentation happens _just before sending the message_. This would also solve https://issues.jboss.org/browse/JGRP-1710.
The problem here is that a very large message might overwhelm flow control: if we allow it to pass, FRAG will generate a high number of fragments out of which many might get discarded due to buffer overflow...
> MFC2: multicast flow control
> ----------------------------
>
> Key: JGRP-1507
> URL: https://issues.jboss.org/browse/JGRP-1507
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: Design.pdf
>
>
> The current flow control protocol (MFC) is slowing things down when we have high traffic in multicast networks (UDP based stack), especially when ethernet flow control (802.3) is disabled.
> One reason is that the number of credits (similar to the window size in TCP) is static, and doesn't change. E.g. it doesn't increase when there's no loss and doesn't shrink when there is loss.
> (This will be addressed by a different JIRA later)
> Another reason is that sender credits are currently only used up when *sending* messages, but not when *receiving* messages. Thus, if we have 50MB of credits, a sender A can send 50MB until A blocks. However, when it receives 20MB of traffic from B while it sends the 50MB, it doesn't take the 20MBs into account.
> Therefore, a receiver S can be overwhelmed by receiving both A's and B's traffic (the switch might even start discarding messages before they reach S).
> The change from MFC to MFC2 is that a sender only maintains 1 'credits' counter (number of bytes): whenever it sends a message, it decrements credits. Whenever it receives traffic from someone else, it also decrements credits. When credits is 0, the sender blocks (asking for more credits). When credits drops below a certain threshold, it multicasts 1/N of the max credits (N = number of cluster members). (TBD: perhaps it should mcast a fixed number, independent of the cluster size).
> The advantage of this scheme is that a sender blocks sooner, and not when it's too late (congestion).
> Example:
> - credits = 100MB
> - Concurrently: A sends 50MB, B sends 30MB and C sends 60MB
> - At time T1, A has sent 20MB, and we've already received 10MB from B and 20 from C, credits is now 50MB
> - At time T2, A sent another 20MB, and received 20MB from C. credits is now 10MB, and A multicasts 35MB (rounded)
> - At T3, A receives another 10MB from B, credits=0
> - At T4, A blocks trying to send its remaining 10MBs, as credits = 0
> - At T5, A receives its 35MB of credits and sends its remaining 10MB, and also receives 20MB from C, and the remaining 10MB from B. credits is now -5 and A would block sending more credits
> - At T6, A multicasts 35MBs of credits
> - At T7, A receives 35MB of credits from B and C, credits= ca 65MB
> - At T8, A receives its own 35MBs of credits, credits=~100MB
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-1960) CDI @Inject of @Stateless @WebService cause WELD-001408 Unsatisfied dependencies
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1960?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1960:
-----------------------------------------------
Stuart Douglas <sdouglas(a)redhat.com> made a comment on [bug 1001610|https://bugzilla.redhat.com/show_bug.cgi?id=1001610]
Rejecting dev_ack as per Martin's comment, as the test is invalid.
> CDI @Inject of @Stateless @WebService cause WELD-001408 Unsatisfied dependencies
> --------------------------------------------------------------------------------
>
> Key: WFLY-1960
> URL: https://issues.jboss.org/browse/WFLY-1960
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB, Web Services
> Affects Versions: 8.0.0.Alpha4
> Reporter: Aslak Knutsen
> Assignee: Martin Kouba
>
> CDI @Inject of @WebService does not work.
> {code}
> import javax.ejb.Stateless;
> import javax.jws.WebService;
>
> @Stateless
> @WebService
> public class TestBean {
> }
>
>
> import javax.inject.Inject;
>
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.asset.EmptyAsset;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.junit.Test;
> import org.junit.runner.RunWith;
>
>
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>
> @Inject
> TestBean bean;
>
> @Deployment
> public static WebArchive createDeployment() {
> WebArchive arch = ShrinkWrap.create(WebArchive.class);
> arch.addClass(TestBean.class);
> arch.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
> return arch;
> }
>
> @Test
> public void fooTest() throws Exception {
>
> }
> }
> {code}
> Using CDI to do a non contextual injection on a class where @EJB is used instead of @Inject works.
> {code}
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>
> @EJB
> TestBean bean;
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months