I would like to execute my code just before #Transactional transaction is started.
#Aspect
#Order(Ordered.HIGHEST_PRECEDENCE)
//#Order(Ordered.LOWEST_PRECEDENCE)
public class SynchronizerAspect {
#Pointcut("execution(public * xxx.xxx.services.*.*(..))")
private void anyServiceOperation() {
}
#Around("anyServiceOperation()")
public Object synchronizerAdvice(ProceedingJoinPoint joinPoint) throws Throwable {
System.out.println("Synchronizing : " + joinPoint.getSignature().getName());
return joinPoint.proceed();
}
When I call a service method marked as #Transactional I always have my aspect code executed inside the transaction:
[INFO] INFO: FETCH created: Fri Oct 30 15:43:11 UTC 2015 duration: 0 connection: 40 statement: 999 resultset: 0
[INFO] paĹş 30, 2015 3:43:11 PM com.mysql.jdbc.log.Slf4JLogger logInfo
[INFO] INFO: QUERY created: Fri Oct 30 15:43:11 UTC 2015 duration: 1 connection: 40 statement: 14 resultset: 15 message: SELECT ##session.tx_isolation
[INFO] paĹş 30, 2015 3:43:11 PM com.mysql.jdbc.log.Slf4JLogger logInfo
[INFO] INFO: FETCH created: Fri Oct 30 15:43:11 UTC 2015 duration: 3 connection: 40 statement: 14 resultset: 15
[INFO] paĹş 30, 2015 3:43:11 PM com.mysql.jdbc.log.Slf4JLogger logInfo
[INFO] INFO: QUERY created: Fri Oct 30 15:43:11 UTC 2015 duration: 1 connection: 40 statement: 999 resultset: 0 message: SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
[INFO] paĹş 30, 2015 3:43:11 PM com.mysql.jdbc.log.Slf4JLogger logInfo
[INFO] INFO: FETCH created: Fri Oct 30 15:43:11 UTC 2015 duration: 0 connection: 40 statement: 999 resultset: 0
[INFO] paĹş 30, 2015 3:43:11 PM com.mysql.jdbc.log.Slf4JLogger logInfo
[INFO] INFO: QUERY created: Fri Oct 30 15:43:11 UTC 2015 duration: 0 connection: 40 statement: 15 resultset: 16 message: SELECT 1
[INFO] paĹş 30, 2015 3:43:11 PM com.mysql.jdbc.log.Slf4JLogger logInfo
[INFO] INFO: FETCH created: Fri Oct 30 15:43:11 UTC 2015 duration: 3 connection: 40 statement: 15 resultset: 16
[INFO] Synchronizing : getCompany
I also set #EnableTransactionManagement(order = 500)
Is there something that I should done to make it working?
Additionally, I use aspectj-maven-plugin:1.7 to weave aspects at the compile time.
Is it so smart and also uses #Ordering?
It doesn't matter how I set #Order aspectj-maven-plugin logs shows that my #Aspect was added before #Transactional
[INFO] Join point 'method-execution(boolean xxx.xxx.services.LicenseServiceImpl.checkLicenseFile(int, int))' in Type 'xxx.xxx.services.LicenseServiceImpl' (LicenseServiceImpl.java:261) advised by around advice from 'xxx.xxx.aop.SynchronizerAspect' (SynchronizerAspect.java:29)
[INFO] Join point 'method-execution(boolean xxx.xxx.services.LicenseServiceImpl.checkLicenseFile(int, int))' in Type 'xxx.xxx.services.LicenseServiceImpl' (LicenseServiceImpl.java:261) advised by around advice from 'org.springframework.transaction.aspectj.AnnotationTransactionAspect' (spring-aspects-4.2.2.RELEASE.jar!AbstractTransactionAspect.class:66(from AbstractTransactionAspect.aj))
OK. I know the answer:
If Spring's proxy-based AOP is used, #Order annotation works fine.
For load-time weaving it is needed to declare aspect precedence:
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.DeclarePrecedence;
#Aspect
#DeclarePrecedence("xxx.xxx.aop.SynchronizerAspect, org.springframework.transaction.aspectj.AnnotationTransactionAspect, *")
public class AspectPrecedence {
// empty
}
To switch from AutoProxy(default) to AspectJ:
#EnableAspectJAutoProxy
#EnableTransactionManagement(mode = AdviceMode.ASPECTJ)
Related
I am running a job where in source, i have oracle sql query to read the rows, followed by sorter transformation. Below are session logs where we can see after the start of sorter transformation [srt] it takes more than 3 hours to process 410516 rows. I am failing to understand if sorter is taking time or source query?
Appreciate your response.
READER_1_1_1> RR_4049 [2022-06-26 23:40:13.888] SQL Query issued to database : (Sun Jun 26 23:40:13 2022)
READER_1_1_1> RR_4050 [2022-06-26 23:49:01.147] First row returned from database to reader : (Sun Jun 26 23:49:01 2022)
TRANSF_1_1_1> SORT_40420 [2022-06-26 23:49:01.148] Start of input for Transformation [srt]. : (Sun Jun 26 23:49:01 2022)
READER_1_1_1> BLKR_16019 [2022-06-27 03:04:51.901] Read [410516] rows, read [0] error rows for source table [DUMMY_src] instance name [DUMMY_src]
READER_1_1_1> BLKR_16008 [2022-06-27 03:04:51.902] Reader run completed.
TRANSF_1_1_1> SORT_40421 [2022-06-27 03:04:51.909] End of input for Transformation [srt]. : (Mon Jun 27 03:04:51 2022)
TRANSF_1_1_1> SORT_40422 [2022-06-27 03:04:52.180] End of output from Sorter Transformation [srt]. Processed 410516 rows (6568256 input bytes; 0 temp I/O bytes). : (Mon Jun 27 03:04:52 2022)
TRANSF_1_1_1> SORT_40423 [2022-06-27 03:04:52.181] End of sort for Sorter Transformation [srt]. : (Mon Jun 27 03:04:52 2022)
WRITER_1_*_1> WRT_8167 [2022-06-27 03:04:52.201] Start loading table
WRT_8035 [2022-06-27 03:09:47.457] Load complete time: Mon Jun 27 03:09:47 2022
I need to a new workspace in OWB11gR2(11.2.0.4) to upgrade OWB11gR1(11.1.0.7). Repository Assistant fails after processing 64%. The following is the error log.
main.TaskScheduler timer[5]20200714#08:45:58.058: 00> oracle.wh.service.impl.assistant.ProcessEngine.display(ProcessEngine.java:2122): % = 0.8051529790660225
main.TaskScheduler timer[5]20200714#08:45:58.058: 00> oracle.wh.service.impl.assistant.ProcessEngine.display(ProcessEngine.java:2122): -token name = LOADJAVA; -token type = 13
main.TaskScheduler timer[5]20200714#08:45:58.058: 00> oracle.wh.service.impl.assistant.ProcessEngine.display(ProcessEngine.java:2122): ProcessEngine.token_db_min_ver =
main.TaskScheduler timer[5]20200714#08:45:58.058: 00> oracle.wh.service.impl.assistant.ProcessEngine.display(ProcessEngine.java:2122): Before processing LOADJAVA Token
main.TaskScheduler timer[5]20200714#08:45:58.058: 00> oracle.wh.service.impl.assistant.ProcessEngine.display(ProcessEngine.java:2122): ... I am in processLoadJavaToken ...
main.AWT-EventQueue-0[6]20200714#08:48:36.036: 00> oracle.wh.ui.jcommon.WhButton#424c414: WhButton setLabel rtsString = Yes
main.AWT-EventQueue-0[6]20200714#08:48:36.036: 00> oracle.wh.ui.jcommon.WhButton#424c414: WhButton setLabel rtsString = No
The following is the list of database patches.
Patch 17906774: applied on Wed Aug 04 11:21:52 BDT 2021
Unique Patch ID: 17692968
Created on 14 May 2014, 22:56:54 hrs PST8PDT
Bugs fixed:
17607032, 17974168, 17669786, 17561509, 16885825, 18274560, 17613052
17461930, 16829998, 17251918, 17435868, 17279666, 17328020, 17006987
18260620, 16833468, 18180599, 17292119, 17340242, 17296559, 15990966
17438322, 17939651, 17359696, 18385759, 17820353, 17939225, 17715818
18192446, 16960088, 17191248, 17422695
Patch 31668908 : applied on Mon Jul 12 16:13:02 BDT 2021
Unique Patch ID: 23822194
Patch description: "OJVM PATCH SET UPDATE 11.2.0.4.201020"
Created on 18 Sep 2020, 03:30:45 hrs PST8PDT
Bugs fixed:
23727132, 19554117, 19006757, 14774730, 18933818, 18458318, 18166577
19231857, 19153980, 19058059, 19007266, 17285560, 17201047, 17056813
19223010, 19852360, 19909862, 19895326, 19374518, 20408829, 21047766
21566944, 19176885, 17804361, 17528315, 21811517, 22253904, 19187988
21911849, 22118835, 22670385, 23265914, 22675136, 24448240, 25067795
24534298, 25076732, 25494379, 26023002, 19699946, 26637592, 27000663
25649873, 27461842, 27952577, 27642235, 28502128, 28915933, 29254615
29774367, 29992392, 29448234, 30160639, 30534664, 30855121, 31306274
30772207, 31476032, 30561292, 28394726, 26716835, 24817447, 23082876
31668867
Patch 31537677 : applied on Thu Jul 08 11:53:10 BDT 2021
Unique Patch ID: 23852314
Patch description: "Database Patch Set Update : 11.2.0.4.201020 (31537677)"
The following is the workaround to fix the issue.
Step 1: Rollback the patches 31668908 and 31537677. OWB does not support with OJVM patch newer than December 2018
Step 2:Re-run the repository assistant.
Ho All,
I have a odd issue with okhttp version 4.9.0. It seems to increase the response time ( client.newCall(request).execute() ). If I increase the connectTimeout to 5 seconds the response time increases to 6 if I increase it to 15 seconds the response time increases to 16 seconds. Below is how I am using the builder.
client = new OkHttpClient.Builder()
.connectionPool(new ConnectionPool(2, 2, TimeUnit.SECONDS))
.cache(null)
.connectTimeout(2, TimeUnit.SECONDS)
.readTimeout(25, TimeUnit.SECONDS).build();
Thanks for any hints!
It is likely getting two or more routes and failing to connect to the first before the second one works. Most likely you have anetwork problem or similar and should fix that.
To confirm add a debugging EventListener
https://square.github.io/okhttp/events/
Since you haven't provided a useful reproduction, we can simulate using an additional route to test against.
val client = OkHttpClient.Builder()
.dns(object: Dns {
override fun lookup(hostname: String): List<InetAddress> {
return listOf<InetAddress>(InetAddress.getByName("198.51.100.0")) + Dns.SYSTEM.lookup("httpbin.org")
}
})
.eventListenerFactory(LoggingEventListener.Factory())
.build()
val response = client.newCall(Request.Builder().url("https://httpbin.org/get").build()).execute()
println(response.body!!.string())
Output will be like the following, not that the first connect takes 10 seconds (the connect timeouts) as it's hitting a dummy IP and then subsequent connections will try the second of the total 5 available IP addresses successfully and the request will continue.
Nov 23, 2020 7:44:01 AM okhttp3.internal.platform.Platform log
INFO: [0 ms] callStart: Request{method=GET, url=https://httpbin.org/get}
Nov 23, 2020 7:44:01 AM okhttp3.internal.platform.Platform log
INFO: [34 ms] proxySelectStart: https://httpbin.org/
Nov 23, 2020 7:44:01 AM okhttp3.internal.platform.Platform log
INFO: [35 ms] proxySelectEnd: [DIRECT]
Nov 23, 2020 7:44:01 AM okhttp3.internal.platform.Platform log
INFO: [36 ms] dnsStart: httpbin.org
Nov 23, 2020 7:44:01 AM okhttp3.internal.platform.Platform log
INFO: [150 ms] dnsEnd: [/198.51.100.0, httpbin.org/3.211.1.78, httpbin.org/35.170.225.136, httpbin.org/34.198.212.59, httpbin.org/52.6.34.179]
Nov 23, 2020 7:44:01 AM okhttp3.internal.platform.Platform log
INFO: [153 ms] connectStart: /198.51.100.0:443 DIRECT
Nov 23, 2020 7:44:11 AM okhttp3.internal.platform.Platform log
INFO: [10164 ms] connectFailed: null java.net.SocketTimeoutException: Connect timed out
Nov 23, 2020 7:44:11 AM okhttp3.internal.platform.Platform log
INFO: [10165 ms] connectStart: httpbin.org/3.211.1.78:443 DIRECT
Nov 23, 2020 7:44:11 AM okhttp3.internal.platform.Platform log
INFO: [10263 ms] secureConnectStart
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10663 ms] secureConnectEnd: Handshake{tlsVersion=TLS_1_2 cipherSuite=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 peerCertificates=[CN=httpbin.org, CN=Amazon, OU=Server CA 1B, O=Amazon, C=US, CN=Amazon Root CA 1, O=Amazon, C=US] localCertificates=[]}
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10676 ms] connectEnd: h2
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10678 ms] connectionAcquired: Connection{httpbin.org:443, proxy=DIRECT hostAddress=httpbin.org/3.211.1.78:443 cipherSuite=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 protocol=h2}
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10679 ms] requestHeadersStart
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10683 ms] requestHeadersEnd
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10903 ms] responseHeadersStart
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10904 ms] responseHeadersEnd: Response{protocol=h2, code=200, message=, url=https://httpbin.org/get}
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10907 ms] responseBodyStart
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10908 ms] responseBodyEnd: byteCount=272
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10908 ms] connectionReleased
Nov 23, 2020 7:44:12 AM okhttp3.internal.platform.Platform log
INFO: [10908 ms] callEnd
{
"args": {},
"headers": {
"Accept-Encoding": "gzip",
"Host": "httpbin.org",
"User-Agent": "okhttp/4.10.0-RC1",
"X-Amzn-Trace-Id": "Root=1-5fbb684d-0b7fa68f2cce945f25b5f1bf"
},
"origin": "81.100.210.134",
"url": "https://httpbin.org/get"
}
I ended up using a solution for Android mobile (smart device) when compiling to be compatible with java 1.8. Just add the below to your gradle.build file under defaultConfig section for the module where you use okhttp.
android.compileOptions.sourceCompatibility 1.8
android.compileOptions.targetCompatibility 1.8
I've just started on Oozie. Hoping someone here can offer some useful advice.
Here is a snippet of the coordinator.xml
<coordinator-app name="weeklyABCFacts" frequency="${coord:days(7)}" start="${start}T00:00Z" end="${end}" timezone="CET" xmlns="uri:oozie:coordinator:0.1">
<controls>
<timeout>-1</timeout>
<concurrency>1</concurrency>
<execution>FIFO</execution>
</controls>
<datasets>
<dataset name="weekly-f_stats-flag" frequency="${coord:days(7)}" initial-instance="2013-07-01T00:00Z" timezone="CET">
<uri-template>${nameNode}/warehouse/hive/f_stats/dt=${YEAR}W${WEEK} </uri-template>
</dataset>
</datasets>
...
</coordinator-app>
The part where my question will relate to is in within the tag. They are normally expressed in the following: "...revenue_feed/${YEAR}/${MONTH}/${DAY}/${HOUR}..."
Can this part be expressed in WEEK? i.e. the last column in table rep below.
Reason for the question is that our date table has a field column called 'iso_week' (e.g. 28, or its corresponding date range is 8 July - 14 July 2013). It looks like the following:
-----------------------------------+
|date_field |iso_week|iso_week_date|
-----------------------------------+
'2013-07-08', '28', '2013W28'
'2013-07-09', '28', '2013W28'
'2013-07-10', '28', '2013W28'
'2013-07-11', '28', '2013W28'
'2013-07-12', '28', '2013W28'
'2013-07-13', '28', '2013W28'
'2013-07-14', '28', '2013W28'
I hope this is clear enough, otherwise, please let me know how else I can be more clear.
There is not (in the 3.3.2 source i'm looking at), but there's nothing stopping you from downloading the source and amending the core/java/org/apache/oozie/coord/CoordELEvaluator.java file, specifically the createURIELEvaluator(String) method:
public static ELEvaluator createURIELEvaluator(String strDate) throws Exception {
ELEvaluator eval = new ELEvaluator();
Calendar date = Calendar.getInstance(DateUtils.getOozieProcessingTimeZone());
// always???
date.setTime(DateUtils.parseDateOozieTZ(strDate));
eval.setVariable("YEAR", date.get(Calendar.YEAR));
eval.setVariable("MONTH", make2Digits(date.get(Calendar.MONTH) + 1));
eval.setVariable("DAY", make2Digits(date.get(Calendar.DAY_OF_MONTH)));
eval.setVariable("HOUR", make2Digits(date.get(Calendar.HOUR_OF_DAY)));
eval.setVariable("MINUTE", make2Digits(date.get(Calendar.MINUTE)));
// add the following line:
eval.setVariable("WEEK", make2Digits(date.get(Calendar.WEEK_OF_YEAR)));
return eval;
}
You should then be able to follow the instructions to recompile oozie
I would note that you should be weary of how week numbers and years don't always fit together nicely - for example week 1 of 2013 actually starts in 2012:
Tue Dec 25 11:11:52 EST 2012 : 2012 W 52
Wed Dec 26 11:11:52 EST 2012 : 2012 W 52
Thu Dec 27 11:11:52 EST 2012 : 2012 W 52
Fri Dec 28 11:11:52 EST 2012 : 2012 W 52
Sat Dec 29 11:11:52 EST 2012 : 2012 W 52
Sun Dec 30 11:11:52 EST 2012 : 2012 W 1 <= Here's your problem
Mon Dec 31 11:11:52 EST 2012 : 2012 W 1
Tue Jan 01 11:11:52 EST 2013 : 2013 W 1 <= 'Fixed' from here
Wed Jan 02 11:11:52 EST 2013 : 2013 W 1
Thu Jan 03 11:11:52 EST 2013 : 2013 W 1
Fri Jan 04 11:11:52 EST 2013 : 2013 W 1
Sat Jan 05 11:11:52 EST 2013 : 2013 W 1
Sun Jan 06 11:11:52 EST 2013 : 2013 W 2
Mon Jan 07 11:11:52 EST 2013 : 2013 W 2
Tue Jan 08 11:11:52 EST 2013 : 2013 W 2
As produced by the following test snippet:
#Test
public void testDates() {
Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
cal.set(2012, 11, 25);
for (int x = 0; x < 15; x++) {
System.err.println(cal.getTime() + " : " + cal.get(Calendar.YEAR)
+ " W " + cal.get(Calendar.WEEK_OF_YEAR));
cal.add(Calendar.DAY_OF_YEAR, 1);
}
}
I have three test classes: FirstTest, SecondTest and ThirdTest. This is how FirstTest class looks like:
public class FirstTest {
#Test
public void test() throws InterruptedException {
System.out.println(this.getClass() + " " + new Date());
Thread.sleep(10_000);
}
#Test
public void test2() throws InterruptedException {
System.out.println(this.getClass() + " " + new Date());
Thread.sleep(10_000);
}
#Test
public void test3() throws InterruptedException {
System.out.println(this.getClass() + " " + new Date());
Thread.sleep(10_000);
}
#Test
public void test4() throws InterruptedException {
System.out.println(this.getClass() + " " + new Date());
Thread.sleep(15_000);
}
}
SecondTest class is identical (10s+10s+10s+15s = 45s total), and ThirdTest contains 10s+10s+10s test methods.
I'm using Maven Surefire plugin with following configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.9</version>
<configuration>
<excludes>
<exclude>${excludeTestPath}</exclude>
</excludes>
<parallel>both</parallel>
<threadCount>20</threadCount>
</configuration>
</plugin>
I'm having problem with understanding how parallel attribute works. I've tried setting "both", "methods" and "classes" values, but got some confusing output. Please, have a look and explain it to me:
parallel='classes'
Concurrency config is parallel='classes', perCoreThreadCount=true,
threadCount=20, useUnlimitedThreads=false
Running experiment.ThirdTest
class experiment.ThirdTest Mon Jun 10 12:00:38 CEST 2013
class experiment.ThirdTest Mon Jun 10 12:00:48 CEST 2013
class experiment.ThirdTest Mon Jun 10 12:00:58 CEST 2013
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.024 sec
Running experiment.SecondTest
class experiment.SecondTest Mon Jun 10 12:00:38 CEST 2013
class experiment.SecondTest Mon Jun 10 12:00:48 CEST 2013
class experiment.SecondTest Mon Jun 10 12:00:58 CEST 2013
class experiment.SecondTest Mon Jun 10 12:01:08 CEST 2013
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 45.054 sec
Running experiment.FirstTest
class experiment.FirstTest Mon Jun 10 12:00:38 CEST 2013
class experiment.FirstTest Mon Jun 10 12:00:48 CEST 2013
class experiment.FirstTest Mon Jun 10 12:00:58 CEST 2013
class experiment.FirstTest Mon Jun 10 12:01:08 CEST 2013
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 45.074 sec
Results :
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
[INFO] Total time: 52.319s
[INFO] Finished at: Mon Jun 10 12:01:48 CEST 2013
[INFO] Final Memory: 22M/354M
This is expected result, three classes were executed parallel, all starting at 12:00:38. Build should take 10s+10s+10s+15s, so about 45s.
parallel='methods'
Concurrency config is parallel='methods', perCoreThreadCount=true,
threadCount=20, useUnlimitedThreads=false
Running experiment.FirstTest
class experiment.FirstTest Mon Jun 10 12:10:23 CEST 2013
class experiment.FirstTest Mon Jun 10 12:10:23 CEST 2013
class experiment.FirstTest Mon Jun 10 12:10:23 CEST 2013
class experiment.FirstTest Mon Jun 10 12:10:23 CEST 2013
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 45.142 sec
Running experiment.SecondTest
class experiment.SecondTest Mon Jun 10 12:10:38 CEST 2013
class experiment.SecondTest Mon Jun 10 12:10:38 CEST 2013
class experiment.SecondTest Mon Jun 10 12:10:38 CEST 2013
class experiment.SecondTest Mon Jun 10 12:10:38 CEST 2013
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 45.037 sec
Running experiment.ThirdTest
class experiment.ThirdTest Mon Jun 10 12:10:53 CEST 2013
class experiment.ThirdTest Mon Jun 10 12:10:53 CEST 2013
class experiment.ThirdTest Mon Jun 10 12:10:53 CEST 2013
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.009 sec
Results :
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
[INFO] Total time: 47.405s
[INFO] Finished at: Mon Jun 10 12:11:04 CEST 2013
[INFO] Final Memory: 22M/354M
This is expected result, all methods were executed parallel within single class. Build should take 15s+15s+10s, so about 45s.
parallel='both'
Concurrency config is parallel='both', perCoreThreadCount=true,
threadCount=20, useUnlimitedThreads=false
Running experiment.FirstTest
class experiment.FirstTest Mon Jun 10 12:18:40 CEST 2013
class experiment.FirstTest Mon Jun 10 12:18:40 CEST 2013
class experiment.FirstTest Mon Jun 10 12:18:40 CEST 2013
class experiment.FirstTest Mon Jun 10 12:18:40 CEST 2013
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 45.18 sec
Running experiment.SecondTest
class experiment.SecondTest Mon Jun 10 12:18:55 CEST 2013
class experiment.SecondTest Mon Jun 10 12:18:55 CEST 2013
class experiment.SecondTest Mon Jun 10 12:18:55 CEST 2013
class experiment.SecondTest Mon Jun 10 12:18:55 CEST 2013
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 45.031 sec
Running experiment.ThirdTest
class experiment.ThirdTest Mon Jun 10 12:19:10 CEST 2013
class experiment.ThirdTest Mon Jun 10 12:19:10 CEST 2013
class experiment.ThirdTest Mon Jun 10 12:19:10 CEST 2013
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.025 sec
Results :
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
[INFO] Total time: 47.521s
[INFO] Finished at: Mon Jun 10 12:19:20 CEST 2013
[INFO] Final Memory: 22M/354M
Now, this one is confusing for me. The build took about 45s, while it should take about 15s (longest test method). Why didn't all three classes start executing at 12:18:40? Doesn't parallel='both' mean that both classes and methods are executed at the same time?
EDIT:
I've found blogpost that mentions the issue.
See this comment from SUREFIRE-814 (from Jan. 2012):
"both" is largely untested for a long time and I have no reason to disbelieve that you're seeing this issue.
It's a safe bet that parallel=both has not received much attention in the interim. I verified that the issue affects Surefire 2.15 and I plan to comment as such and vote on the ticket (as soon as I get my signup confirmation). I recommend more people vote on the ticket.
This issue is fixed in 2.16.
Similar issues should work properly as well
https://issues.apache.org/jira/browse/SUREFIRE-797