Menu
▾
▴
kieker-developers — Kieker developer list
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
(4) |
Jun
(1) |
Jul
(4) |
Aug
(5) |
Sep
(2) |
Oct
(6) |
Nov
(3) |
Dec
(1) |
| 2014 |
Jan
(3) |
Feb
(2) |
Mar
(4) |
Apr
(3) |
May
(7) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(7) |
Nov
(2) |
Dec
(5) |
| 2015 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(1) |
| 2016 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
(2) |
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: David G. R. <dav...@un...> - 2021-10-16 16:28:25
|
12th Symposium on Software Performance 2021 (SSP 2021) Call for Participation Leipzig, Germany November 09-10, 2021 https://www.performance-symposium.org/2021/ ------------------------------------------------------------------------------- The Symposium on Software Performance (SSP) brings together researchers and practitioners interested in software performance, where "performance" is understood both in a classical sense as “the amount of useful work accomplished by a software system compared to the time and resources used”, as well as in a broader sense as "the manner in which or the efficiency with which a software system reacts or fulfills its intended purpose". The scope of SSP spans measurement, modeling, benchmark design, and run-time management. The focus is both on classical performance metrics such as response time, throughput, and resource utilization, as well as on the relationship of such metrics to other software quality attributes including but not limited to scalability, elasticity, (energy) efficiency, dependability (in terms of availability and reliability), resilience, security, and privacy. Topics of interest include the design of metrics, benchmarks, and tools for quantitative system evaluation and analysis, as well as the development of methodologies, techniques and tools for modeling, measurement, load testing, monitoring, profiling, workload characterization, and run-time management of software systems with respect to the mentioned quality attributes. The symposium is organized by the three established research groups Descartes, Kieker, and Palladio; thus this symposium also serves as a joint community meeting. Descartes' focus are techniques and tools for engineering self-aware computing systems designed for maximum dependability and efficiency. Kieker is a well‐established tool and approach for monitoring software performance of complex, large, and distributed IT systems. Palladio is a likewise‐established tool and approach for modeling architectures of IT systems and for simulating quality properties, such as for example performance or reliability metrics. ------------------------------------------------------------------------------- PROGRAM SSP 2021 takes place in Leipzig from November 9 to 10, 2021. The preliminary program is available at https://www.performance-symposium.org/2021/program/ ------------------------------------------------------------------------------- REGISTRATION Registration is free and open until October 20th! To register to SSP 2021, please fill in the form at the following link: https://www.performance-symposium.org/2021/registration/ -------------------------------------------------------------------------------- CONTACT David Georg Reichelt, Leipzig University, University Computing Centre,+49 341 97 33300, dav...@un... |
|
From: Andre v. H. <and...@un...> - 2021-10-08 13:45:12
|
Hi all, today, we released version 1.15 of our Kieker framework for application performance monitoring and dynamic software analysis. As usual, the release is available for download at https://kieker-monitoring.net/download/. - New features (selection) - Migration of analysis stages to the TeeTime-based Kieker analysis. - Added new analysis stages from the iObserve research project - Improvements and refactorings - Improved AspectJ probes, e.g., by introducing before/after advices for cflow pointcuts, OpenJDK 11 support - Refactored the file system writer - Build scripts and infrastructure - Replaced additional local Jar dependencies by using the Maven dependencies - Converted Kieker tools to multi-project builds - Use of GitHub actions to test common platforms (Linux, Mac, Windows) and Java versions - Documentation - Migrated the deprecated LaTeX-based user guide to Read The Docs (https://kieker-monitoring.readthedocs.io/en/latest/) -- Dr.-Ing. Andre van Hoorn University of Hamburg, Department of Informatics Software Engineering and Construction Methods and...@un... |
|
From: Andre v. H. <van...@in...> - 2020-05-13 20:31:07
|
Dear all, On May 12, 2020, we released version 1.14 of our Kieker framework for application performance monitoring and dynamic software analysis. As usual, the release is available for download at http://kieker-monitoring.net/download/. Release Notes: http://kieker-monitoring.net/release-notes/ Many thanks to all contributors! Best, André -- Dr.-Ing. André van Hoorn University of Stuttgart, Inst. of Software Technology Reliable Software Systems Group Universitätsstraße 38, D-70569 Stuttgart, Germany Room: 1.332 Phone: +49 (0)711 685-88-252, Fax: -472 E-Mail: van...@in... https://www.iste.uni-stuttgart.de/institute/team/van-Hoorn/ http://kieker-monitoring.net/, http://research.spec.org/ |
|
From: Simon E. <sim...@un...> - 2019-05-08 11:36:32
|
====== 10th Symposium on Software Performance 2019 ======
Call for Papers
Würzburg, November 5-6, 2019
https://www.performance-symposium.org/2019/
The Symposium on Software Performance (SSP) brings together researchers
and practitioners interested in software performance, where "performance"
is understood both in classical sense as “the amount of useful work ac-
complished by a software system compared to the time and resources used”,
as well as in a broader sense as "the manner in which or the efficiency
with which a software system reacts or fulfills its intended purpose".
The scope of SSP spans measurement, modeling, benchmark design, and run-
time management. The focus is both on classical performance metrics such
as response time, throughput and resource utilization, as well as on the
relationship of such metrics to other software quality attributes includ-
ing but not limited to scalability, elasticity, (energy) efficiency, de-
pendability (in terms of availability and reliability), resilience, secu-
rity and privacy. Topics of interest include the design of metrics, bench-
marks and tools for quantitative system evaluation and analysis, as well
as the development of methodologies, techniques and tools for modeling,
measurement, load testing, monitoring, profiling, workload characteriza-
tion and run-time management of software systems with respect to the men-
tioned quality attributes.
The symposium is organized by the three established research groups
Descartes, Kieker, and Palladio; thus this symposium also serves as a
joint community meeting. Descartes' focus are techniques and tools for
engineering self-aware computing systems designed for maximum dependabil-
ity and efficiency. Kieker is a well-established tool and approach for
monitoring software performance of complex, large, and distributed IT sys-
tems. Palladio is a likewise-established tool and approach for modeling
architectures of IT systems and for simulating quality properties, such
as for example performance or reliability metrics.
SSP 2019 is supported by the GI special interest group "Softwaretechnik“.
Submission are thought for plans, ongoing work, or results on:
- Software quality analysis in regard to:
- Performance
- Scalability and elasticity
- Energy efficiency
- Dependability and resilience
- Security and privacy
- Application performance measurement and management
- Performance measurement and benchmarking
- Performance modeling (modeling, simulation, extraction and calibration)
- Automated run-time management of software systems
- Automated approaches for performance problem detection and resolution
- Performance-related challenges in industrial software systems
- Application of Descartes, Kieker, or Palladio in projects
We solicit technical papers (maximum 3 pages) and extended
abstracts for industry or experience talks (maximum 700 words). Submis-
sion details, see web page. Submission deadlines are in August/September
2019, see web pages.
Easy Chair: https://easychair.org/my/conference.cgi?conf=ssp2019
Proceedings: Accepted Papers will appear in the GI Softwaretechnik-Trends.
Important Dates:
- Aug. 15, 2019 at 23.59 AoE Abstract submission
- Sep. 02, 2019 at 23.59 AoE Paper submission
- Oct. 01, 2019 Acceptance Notification
- Oct. 15, 2019 Camera ready papers
- Oct. 15, 2019 Program announcement
- Oct. 20, 2019 Registration deadline
- Nov. 04, 2019 Developer meetings (participation welcome)
- Nov. 05-06, 2019 Technical symposium program
Steering Committee:
- Steffen Becker, University of Stuttgart
- Wilhelm Hasselbring, Kiel University
- André van Hoorn, University of Stuttgart
- Samuel Kounev, University of Würzburg
- Ralf Reussner, KIT/FZI
- Anne Koziolek, KIT
Program Committee Chair:
- Nikolas Herbst, Universität Würzburg
Program Committee:
- Dusan Okanovic, University of Stuttgart
- Teerat Pitakrat, University of Stuttgart
- Reiner Jung, Kiel University
- Henning Schnoor, Kiel University
- Holger Knoche, Kiel University
- Norbert Schmitt, University of Würzburg
- Johannes Grohmann, University of Würzburg
- Sebastian Krach, KIT/FZI
- Dominik Werle, KIT
- Robert Heinrich, KIT
- Holger Eichelberger, University of Hildesheim
- Johannes Kroß, Fortiss Gmbh
Local Organizers:
- Simon Eismann, University of Würzburg
- David Hock, Infosim
Contact: Dr. Nikolas Herbst, University of Würzburg – Software Engineer-
ing Group, Tel. +49 931 31 83059, nik...@un...
------------------------------------------------------------------------------------------
M.Sc. Simon Eismann
Doctoral Researcher
Chair of Software Engineering
Department of Computer Science
University of Würzburg
Am Hubland, Informatikgebäude (M2), Room 107/108
97074 Würzburg, Germany
Phone: +49 (931) 31 89655, Fax: +49 (931) 31-86603
http://go.uni-wuerzburg.de/eismann/
------------------------------------------------------------------------------------------
|
|
From: Jin,Wuxia <wj...@dr...> - 2018-03-22 18:06:39
|
@Christian<mailto:chr...@em...> @Nils Dear, I think you are right. I checked the source code (an open source: https://github.com/b3log/solo/blob/master/src/main/java/org/b3log/solo/service/UserMgmtService.java ). UserRepositoryImpl is extended from interface UserRepository. And UserRepository is injected with @Inject (a customized implementation similar to Spring @inject). It seems like it uses javassist. But it's still not clear to me, maybe because of my unfamiliar to 'Inject' mechanism. Besides, I haven't found the reason why is "jvstd" instead of "javassist". Thanks lot for your help. Best regards, Wuxia ________________________________ From: Christian Wulf <chr...@em...> Sent: Thursday, March 22, 2018 5:14:08 AM To: kie...@li...; Jin,Wuxia Subject: Re: [Kieker-developers] ask help - why do className and methodName in monitoring log are changed Hi Wuxia, I agree with Nils. Some technology wraps around the class and its methods, for example, Spring AOP or Javassist. However, Javassist typically uses the infix "javassist" instead of "jvstd". Unfortunately, I couldn't find anything about "jvstd" with Google. Bets regards, Christian Am 22.03.2018 um 07:08 schrieb Nils Christian Ehmke: Hello Wuxia, Kieker usually does not change the method's name (except of course you implement your own probe which does that). It looks rather to me like there is some kind of proxy around your UserRepository component. This would certainly explain the unusual class and method names. Can you verify this? Best regards Nils Am 22.03.2018 um 06:05 schrieb Jin,Wuxia: Dear all, I would like to ask for help about monitoring logs by using kieker. Some classes and method names are changed in monitoring logs. Why? I'll show an example. The following is monitoring log with three records: $1;1521681920746370149;public org.json.JSONObject org.b3log.solo.repository.impl.UserRepositoryImpl.get(java.lang.String);<no-session-id>;647533183922869302;1521681920746345807;1521681920746370102;jwx-VirtualBox;34;16 $1;1521681920746370366;public final org.json.JSONObject org.b3log.solo.repository.impl.UserRepositoryImpl_$$_jvstd92_33._d8get(java.lang.String);<no-session-id>;647533183922869302;1521681920746343709;1521681920746370320;jwx-VirtualBox;33;15 $1;1521681920746370719;public final org.json.JSONObject org.b3log.solo.repository.impl.UserRepositoryImpl_$$_jvstd92_33.get(java.lang.String);<no-session-id>;647533183922869302;1521681920746336723;1521681920746370671;jwx-VirtualBox;32;14 (1) In the source code, the real class name is org.b3log.solo.repository.impl.UserRepositoryImpl. The real method name is get(). In monitoring log, why UserRepositoryImpl is changed to UserRepositoryImpl_$$_jvstd92_33? Why get() is changed to _d8get()? (2) In general, behind such this modification, what's the naming mechanism in the monitoring records? Where can I find this modification mechanism in the source code? Thank you for your help. Looking forward to your reply. Best regards, Wuxia Jin ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsdm.link%2Fslashdot&data=02%7C01%7Cwj86%40drexel.edu%7Ce4aa5164dd914264096308d58fd52ec9%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C1%7C636573068157555695&sdata=Oa7%2F4%2FQMFZoAkYocVNex1wjRg5Yk1Hf5TnLItvuCfxU%3D&reserved=0> _______________________________________________ Kieker-developers mailing list Kie...@li...<mailto:Kie...@li...> https://lists.sourceforge.net/lists/listinfo/kieker-developers<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fkieker-developers&data=02%7C01%7Cwj86%40drexel.edu%7Ce4aa5164dd914264096308d58fd52ec9%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C1%7C636573068157555695&sdata=4DMBX1yCI%2Bmdn6NMO6ZyRawUcW%2BEBMngjcKi5Dg1IRE%3D&reserved=0> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsdm.link%2Fslashdot&data=02%7C01%7Cwj86%40drexel.edu%7Ce4aa5164dd914264096308d58fd52ec9%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C1%7C636573068157555695&sdata=Oa7%2F4%2FQMFZoAkYocVNex1wjRg5Yk1Hf5TnLItvuCfxU%3D&reserved=0> _______________________________________________ Kieker-developers mailing list Kie...@li...<mailto:Kie...@li...> https://lists.sourceforge.net/lists/listinfo/kieker-developers<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fkieker-developers&data=02%7C01%7Cwj86%40drexel.edu%7Ce4aa5164dd914264096308d58fd52ec9%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C1%7C636573068157555695&sdata=4DMBX1yCI%2Bmdn6NMO6ZyRawUcW%2BEBMngjcKi5Dg1IRE%3D&reserved=0> -- M.Sc. Christian Wulf Research Assistant Software Engineering Group Dept. Computer Science Christian-Albrechts-Platz 4 University of Kiel 24118 Kiel, Germany Room: 1213 Phone: +49 431 880 2776 Fax: +49 431 880 7617 Email: ch...@in...<mailto:ch...@in...> WWW: http://se.informatik.uni-kiel.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fse.informatik.uni-kiel.de%2F&data=02%7C01%7Cwj86%40drexel.edu%7Ce4aa5164dd914264096308d58fd52ec9%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C1%7C636573068157555695&sdata=2G%2BzSq9bfht9FtEc571Il4wysL28nX3m7YESaAiWEnM%3D&reserved=0> |
|
From: Christian W. <chr...@em...> - 2018-03-22 09:13:42
|
Hi Wuxia, I agree with Nils. Some technology wraps around the class and its methods, for example, Spring AOP or Javassist. However, Javassist typically uses the infix "javassist" instead of "jvstd". Unfortunately, I couldn't find anything about "jvstd" with Google. Bets regards, Christian Am 22.03.2018 um 07:08 schrieb Nils Christian Ehmke: > Hello Wuxia, > > Kieker usually does not change the method's name (except of course you > implement your own probe which does that). It looks rather to me like > there is some kind of proxy around your UserRepository component. This > would certainly explain the unusual class and method names. Can you > verify this? > > Best regards > > Nils > > Am 22.03.2018 um 06:05 schrieb Jin,Wuxia: >> >> Dear all, >> >> >> I would like to ask for help about monitoring logs by using kieker. >> >> >> Some classes and method names are changed in monitoring logs. Why? >> >> I'll show an example. >> >> >> The following is monitoring log with three records: >> >> >> $1;1521681920746370149;public org.json.JSONObject >> org.b3log.solo.repository.impl.UserRepositoryImpl.get(java.lang.String);<no-session-id>;647533183922869302;1521681920746345807;1521681920746370102;jwx-VirtualBox;34;16 >> $1;1521681920746370366;public final org.json.JSONObject >> org.b3log.solo.repository.impl.UserRepositoryImpl*_$$_jvstd92_33._d8*get(java.lang.String);<no-session-id>;647533183922869302;1521681920746343709;1521681920746370320;jwx-VirtualBox;33;15 >> $1;1521681920746370719;public final org.json.JSONObject >> org.b3log.solo.repository.impl.UserRepositoryImpl*_$$_jvstd92_33*.get(java.lang.String);<no-session-id>;647533183922869302;1521681920746336723;1521681920746370671;jwx-VirtualBox;32;14 >> >> (1) In the source code, the real class >> nameis org.b3log.solo.repository.impl.UserRepositoryImpl. The real >> method name is get(). In monitoring log, why UserRepositoryImpl is >> changed to UserRepositoryImpl_$$_jvstd92_33? Why get() is changed to >> _d8get()? >> >> (2) In general, behind such this modification, what's the naming >> mechanism in the monitoring records? >> Where can I find this modification mechanism in the source code? >> >> Thank you for your help. >> Looking forward to your reply. >> >> Best regards, >> Wuxia Jin >> >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> >> _______________________________________________ >> Kieker-developers mailing list >> Kie...@li... >> https://lists.sourceforge.net/lists/listinfo/kieker-developers > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Kieker-developers mailing list > Kie...@li... > https://lists.sourceforge.net/lists/listinfo/kieker-developers -- M.Sc. Christian Wulf Research Assistant Software Engineering Group Dept. Computer Science Christian-Albrechts-Platz 4 University of Kiel 24118 Kiel, Germany Room: 1213 Phone: +49 431 880 2776 Fax: +49 431 880 7617 Email: ch...@in... WWW: http://se.informatik.uni-kiel.de/ |
|
From: Nils C. E. <ni...@rh...> - 2018-03-22 06:08:25
|
Hello Wuxia, Kieker usually does not change the method's name (except of course you implement your own probe which does that). It looks rather to me like there is some kind of proxy around your UserRepository component. This would certainly explain the unusual class and method names. Can you verify this? Best regards Nils Am 22.03.2018 um 06:05 schrieb Jin,Wuxia: > > Dear all, > > > I would like to ask for help about monitoring logs by using kieker. > > > Some classes and method names are changed in monitoring logs. Why? > > I'll show an example. > > > The following is monitoring log with three records: > > > $1;1521681920746370149;public org.json.JSONObject > org.b3log.solo.repository.impl.UserRepositoryImpl.get(java.lang.String);<no-session-id>;647533183922869302;1521681920746345807;1521681920746370102;jwx-VirtualBox;34;16 > $1;1521681920746370366;public final org.json.JSONObject > org.b3log.solo.repository.impl.UserRepositoryImpl*_$$_jvstd92_33._d8*get(java.lang.String);<no-session-id>;647533183922869302;1521681920746343709;1521681920746370320;jwx-VirtualBox;33;15 > $1;1521681920746370719;public final org.json.JSONObject > org.b3log.solo.repository.impl.UserRepositoryImpl*_$$_jvstd92_33*.get(java.lang.String);<no-session-id>;647533183922869302;1521681920746336723;1521681920746370671;jwx-VirtualBox;32;14 > > (1) In the source code, the real class nameis > org.b3log.solo.repository.impl.UserRepositoryImpl. The real method > name is get(). In monitoring log, why UserRepositoryImpl is changed to > UserRepositoryImpl_$$_jvstd92_33? Why get() is changed to _d8get()? > > (2) In general, behind such this modification, what's the naming > mechanism in the monitoring records? > Where can I find this modification mechanism in the source code? > > Thank you for your help. > Looking forward to your reply. > > Best regards, > Wuxia Jin > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Kieker-developers mailing list > Kie...@li... > https://lists.sourceforge.net/lists/listinfo/kieker-developers |
|
From: Jin,Wuxia <wj...@dr...> - 2018-03-22 05:05:59
|
Dear all, I would like to ask for help about monitoring logs by using kieker. Some classes and method names are changed in monitoring logs. Why? I'll show an example. The following is monitoring log with three records: $1;1521681920746370149;public org.json.JSONObject org.b3log.solo.repository.impl.UserRepositoryImpl.get(java.lang.String);<no-session-id>;647533183922869302;1521681920746345807;1521681920746370102;jwx-VirtualBox;34;16 $1;1521681920746370366;public final org.json.JSONObject org.b3log.solo.repository.impl.UserRepositoryImpl_$$_jvstd92_33._d8get(java.lang.String);<no-session-id>;647533183922869302;1521681920746343709;1521681920746370320;jwx-VirtualBox;33;15 $1;1521681920746370719;public final org.json.JSONObject org.b3log.solo.repository.impl.UserRepositoryImpl_$$_jvstd92_33.get(java.lang.String);<no-session-id>;647533183922869302;1521681920746336723;1521681920746370671;jwx-VirtualBox;32;14 (1) In the source code, the real class name is org.b3log.solo.repository.impl.UserRepositoryImpl. The real method name is get(). In monitoring log, why UserRepositoryImpl is changed to UserRepositoryImpl_$$_jvstd92_33? Why get() is changed to _d8get()? (2) In general, behind such this modification, what's the naming mechanism in the monitoring records? Where can I find this modification mechanism in the source code? Thank you for your help. Looking forward to your reply. Best regards, Wuxia Jin |
|
From: Andre v. H. <van...@in...> - 2017-11-11 18:13:13
|
Hi Reiner, thanks. I agree that we need to clean this up. Also added a retrospective of the meeting to the agenda of the next dev meeting. André On 09.11.2017 15:13, Reiner Jung wrote: > Hello everyone, > > it looks like our meeting yesterday was quite productive. > Unfortunately, I couldn't attend due to university business. So I added > in advance my input, and tried to read the agenda & minutes document, > but it is rather inaccessible. It might be helpful to do the following > thing with this document and also for future documents: > > - Make clear which points where discussed > - What are TODOs (tickets)? > - What was input to the discussion? > - What is the result?/What did we agree on? > > In context of the meeting yesterday, this would result in the removal > of my notes, where they are no longer needed, converted into action > where this is applicable. This would help to understand the outcome of > the meeting. > > BTW: Maybe there is a less interesting presentation today and someone > needs to do something to not fall asleep. Then you might go over the > document and clean it up. > > https://kieker-monitoring.atlassian.net/wiki/spaces/MEET/pages/55410689/2017-11-08-SSP-Karlsruhe > > Thanks & Cheers from Schleswig (German outback with almost no Internet) > Reiner > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Kieker-developers mailing list > Kie...@li... > https://lists.sourceforge.net/lists/listinfo/kieker-developers > -- Dr.-Ing. André van Hoorn University of Stuttgart, Inst. of Software Technology Reliable Software Systems (RSS) Group Universitätsstraße 38, D-70569 Stuttgart, Germany Room: 1.332 Phone: +49 (0)711 685-88-252, Fax: -472 E-Mail: van...@in... http://www.iste.uni-stuttgart.de/rss/people/vanhoorn/ http://kieker-monitoring.net/, http://research.spec.org/ == Calls for Contributions: *QUDOS* 2018: 4th International Workshop on Quality-Aware DevOps (Co-located with ACM/SPEC ICPE 2018 in Berlin, Germany) Deadline for full and tool papers: Dec 20, 2017 http://2018.qudos-workshop.org/ *ICPE* 2018: 9th ACM/SPEC Int. Conference on Performance Engineering Deadline for work-in-progress and vision papers: Jan 10, 2018 https://icpe2018.spec.org/ == |
|
From: Reiner J. <rei...@em...> - 2017-11-09 15:07:02
|
Hello everyone, it looks like our meeting yesterday was quite productive. Unfortunately, I couldn't attend due to university business. So I added in advance my input, and tried to read the agenda & minutes document, but it is rather inaccessible. It might be helpful to do the following thing with this document and also for future documents: - Make clear which points where discussed - What are TODOs (tickets)? - What was input to the discussion? - What is the result?/What did we agree on? In context of the meeting yesterday, this would result in the removal of my notes, where they are no longer needed, converted into action where this is applicable. This would help to understand the outcome of the meeting. BTW: Maybe there is a less interesting presentation today and someone needs to do something to not fall asleep. Then you might go over the document and clean it up. https://kieker-monitoring.atlassian.net/wiki/spaces/MEET/pages/55410689/2017-11-08-SSP-Karlsruhe Thanks & Cheers from Schleswig (German outback with almost no Internet) Reiner -- Dr.-Ing. Reiner Jung, Software Engineering Group Dept. Computer Science, Kiel University, D-24118 Kiel, Germany Tel: +49 (0)431 880-2776, Fax: -7617 Email: rei...@em... http://se.informatik.uni-kiel.de/ |
|
From: Christian W. <chr...@em...> - 2017-08-07 14:53:30
|
Hi everybody, I just want to refer to an interesting library for writing and execution integration tests: https://www.testcontainers.org/ Bye Christian -- M.Sc. Christian Wulf Research Assistant Software Engineering Group Dept. Computer Science Christian-Albrechts-Platz 4 University of Kiel 24118 Kiel, Germany Room: 1213 Phone: +49 431 880 2776 Fax: +49 431 880 7617 Email: ch...@in... WWW: http://se.informatik.uni-kiel.de/ |
|
From: Andre v. H. <van...@in...> - 2017-02-07 10:26:39
|
Hi Reiner, thanks for your reply. I fully agree. We had a look at Travis initially but it turned out that it had some limitations. But we might want to revisit it. I would still be an favor of a hosted solution, but also a self-hosted solution could still be an option (e.g., Jenkins equipped with stages, or GoCD that is now the only solution pushed by Thoughtworks (who were also operating SnapCI)). Thanks, André On 07.02.2017 09:26, Reiner Jung wrote: > Hi everyone, > > this is a major setback, especially as so much work was put into > migrating to Snap CI (thanks to all working on that). However, the > workflows, we developed can stay and be reused to reimplement the CI > somewhere else. This issue can be solved following two avenues: > a) Look for another free of charge service somewhere else which > provides similar integration (e.g., Travis CI). However ,there is a > risk that they close down or transform their services into paid > services. > b) Look for software which is simple and we can host on university > infrastructure. This might be increasingly interesting as universities > try to stack up systems for long-living data and software processes. > > Cheers > Reiner > > > On Tue, 7 Feb 2017 08:58:07 +0100 > Andre van Hoorn <van...@in...> wrote: > >> Hi all, >> >> disappointing and unexpected news: Snap CI will stop its service. >> Unfortunately, this means that we need to find an alternative for >> a staged (and hosted) CD pipeline by Aug 2017, latest. We'll keep >> you posted. If you have ideas, please do not hesitate to share >> them. >> >> Best, André >> >> -------- Forwarded Message -------- >> Subject: Snap CI is going away >> Date: Mon, 6 Feb 2017 14:08:43 -0600 (CST) >> From: Louda from Snap CI <lb...@th...> >> Reply-To: su...@sn... >> To: ci...@ki... >> >> >> >> <http://engage.thoughtworks.com/SD0E0P0Yn0u0QQp0A00XPo2> >> >> Hello All, >> >> We have some bad news for you today -- we are canceling Snap CI. >> >> *Why are we canceling Snap? * >> >> While Snap users love the tool, and we truly believe this offers the >> best hosted CI/CD experience in the market, we have not made the major >> impact we feel was necessary to continue support of the tool. >> >> We are a mission driven company. We are focused on helping our >> industry improve, think differently, and work differently. The >> decision is based on the intent to maximize impact on how software is >> built, therefore we are concentrating our efforts on our open source >> tool, GoCD. >> >> *How long will Snap be available for?* >> >> It is our intention to provide Snap CI service for the next 6 months. >> Initially, we will provide a similar service as we do now - critical >> bugs will be fixed and support will be provided as before. However, >> development on new features will be immediately stopped. Support will >> continue throughout the 6 month period but we do expect to stop the >> support for new repositories and to limit configuration changes to >> Snap CI builds to encourage migration to other tools later in the end >> of life (EOL) period. You can review our visual timeline (see below) >> for details of the EOL period. >> >> *How will you communicate the changes and updates to the EOL timeline >> for Snap?* >> >> We will not remove or change any Snap CI features or support without >> first informing you. We will continue to inform you of any changes to >> Snap through this newsletter, our website >> <http://engage.thoughtworks.com/Q0XE0YD0Q30nP0QAP00pup0>, and in-app >> notifications. >> *What happens now? * >> >> The most immediate change is that no new users will be allowed to sign >> up to Snap CI. This will impact you if you want to add new >> collaborators to Snap CI. You can read more about this in our FAQ >> <http://engage.thoughtworks.com/Q0XE0YD0Q30nP0QAP00pup0>. We will also >> stop charging for Snap CI use. Those of you paying monthly will >> receive no further charges to your credit card and your subscription >> will be extended for free until after the EOL period is over. >> Likewise those on invoices will be automatically extended for free. >> >> >> We know that canceling Snap CI is likely to be an inconvenience for >> you and your teams. We will do our best to make this transition as >> smooth as possible. We have already provided comprehensive >> information about the EOL timeline as well as a full FAQ on our >> website <http://engage.thoughtworks.com/Q0XE0YD0Q30nP0QAP00pup0>. As >> we add more to this information we will update you. If you have any >> immediate questions that we have not already covered, please don't >> hesitate to ask, and of course, you will still have access to our >> first-class support team at su...@sn... >> <http://engage.thoughtworks.com/HQ0000P0QpqYXEu0nAD004P>. >> Finally, we wanted to thank you for being a supporter of Snap CI. We >> very much appreciate it. >> >> - Louda and the Snap team >> >> ------------------------------------------------------------------------ >> >> EOL Timeline >> >> >> You are receiving this email because you had registered for Snap at >> https://snap-ci.com >> <http://engage.thoughtworks.com/tPEp0P0XQY0nr00QDu000A5> at some point >> in time. This newsletter is a relatively infrequent update that we >> plan to use to let our users know of the latest happenings in the >> world of Snap. Our intent is not to spam you, though. If you would >> like to unsubscribe to this email, just let us know >> <http://engage.thoughtworks.com/JD0nQP06AE0QsXY0Pp000u0> and that will >> be the last you hear from us! We promise! >> >> 814 Mission Street >> 5th Floor >> San Francisco, CA 94103 >> *T* + 1 415 273 1389 >> *F* + 1 415 986 2964 >> >> twitter <http://engage.thoughtworks.com/a0000n0APQ0Y00tE7DQXupP> >> >> <http://engage.thoughtworks.com/I0A08QY0nupuQP0P0X0DE00> >> >> This email was sent to ci...@ki.... If you no longer wish >> to receive these emails you may manage your email preferences >> <http://engage.thoughtworks.com/u/VYDw000PXA0E000QnuPpaQ0> at any >> time. >> >> > > > -- Dr.-Ing. André van Hoorn Interim Professor (Prof.-Vertr.) University of Stuttgart, Inst. of Software Technology Reliable Software Systems (RSS) Group Universitätsstraße 38, D-70569 Stuttgart, Germany Room: 1.345 Phone: +49 (0)711 685-88-252, Fax: -472 E-Mail: van...@in... http://www.iste.uni-stuttgart.de/rss/people/vanhoorn/ http://kieker-monitoring.net/, http://research.spec.org/ |
|
From: Reiner J. <rei...@em...> - 2017-02-07 08:26:40
|
Hi everyone, this is a major setback, especially as so much work was put into migrating to Snap CI (thanks to all working on that). However, the workflows, we developed can stay and be reused to reimplement the CI somewhere else. This issue can be solved following two avenues: a) Look for another free of charge service somewhere else which provides similar integration (e.g., Travis CI). However ,there is a risk that they close down or transform their services into paid services. b) Look for software which is simple and we can host on university infrastructure. This might be increasingly interesting as universities try to stack up systems for long-living data and software processes. Cheers Reiner On Tue, 7 Feb 2017 08:58:07 +0100 Andre van Hoorn <van...@in...> wrote: > Hi all, > > disappointing and unexpected news: Snap CI will stop its service. > Unfortunately, this means that we need to find an alternative for > a staged (and hosted) CD pipeline by Aug 2017, latest. We'll keep > you posted. If you have ideas, please do not hesitate to share > them. > > Best, André > > -------- Forwarded Message -------- > Subject: Snap CI is going away > Date: Mon, 6 Feb 2017 14:08:43 -0600 (CST) > From: Louda from Snap CI <lb...@th...> > Reply-To: su...@sn... > To: ci...@ki... > > > > <http://engage.thoughtworks.com/SD0E0P0Yn0u0QQp0A00XPo2> > > Hello All, > > We have some bad news for you today -- we are canceling Snap CI. > > *Why are we canceling Snap? * > > While Snap users love the tool, and we truly believe this offers the > best hosted CI/CD experience in the market, we have not made the major > impact we feel was necessary to continue support of the tool. > > We are a mission driven company. We are focused on helping our > industry improve, think differently, and work differently. The > decision is based on the intent to maximize impact on how software is > built, therefore we are concentrating our efforts on our open source > tool, GoCD. > > *How long will Snap be available for?* > > It is our intention to provide Snap CI service for the next 6 months. > Initially, we will provide a similar service as we do now - critical > bugs will be fixed and support will be provided as before. However, > development on new features will be immediately stopped. Support will > continue throughout the 6 month period but we do expect to stop the > support for new repositories and to limit configuration changes to > Snap CI builds to encourage migration to other tools later in the end > of life (EOL) period. You can review our visual timeline (see below) > for details of the EOL period. > > *How will you communicate the changes and updates to the EOL timeline > for Snap?* > > We will not remove or change any Snap CI features or support without > first informing you. We will continue to inform you of any changes to > Snap through this newsletter, our website > <http://engage.thoughtworks.com/Q0XE0YD0Q30nP0QAP00pup0>, and in-app > notifications. > *What happens now? * > > The most immediate change is that no new users will be allowed to sign > up to Snap CI. This will impact you if you want to add new > collaborators to Snap CI. You can read more about this in our FAQ > <http://engage.thoughtworks.com/Q0XE0YD0Q30nP0QAP00pup0>. We will also > stop charging for Snap CI use. Those of you paying monthly will > receive no further charges to your credit card and your subscription > will be extended for free until after the EOL period is over. > Likewise those on invoices will be automatically extended for free. > > > We know that canceling Snap CI is likely to be an inconvenience for > you and your teams. We will do our best to make this transition as > smooth as possible. We have already provided comprehensive > information about the EOL timeline as well as a full FAQ on our > website <http://engage.thoughtworks.com/Q0XE0YD0Q30nP0QAP00pup0>. As > we add more to this information we will update you. If you have any > immediate questions that we have not already covered, please don't > hesitate to ask, and of course, you will still have access to our > first-class support team at su...@sn... > <http://engage.thoughtworks.com/HQ0000P0QpqYXEu0nAD004P>. > Finally, we wanted to thank you for being a supporter of Snap CI. We > very much appreciate it. > > - Louda and the Snap team > > ------------------------------------------------------------------------ > > EOL Timeline > > > You are receiving this email because you had registered for Snap at > https://snap-ci.com > <http://engage.thoughtworks.com/tPEp0P0XQY0nr00QDu000A5> at some point > in time. This newsletter is a relatively infrequent update that we > plan to use to let our users know of the latest happenings in the > world of Snap. Our intent is not to spam you, though. If you would > like to unsubscribe to this email, just let us know > <http://engage.thoughtworks.com/JD0nQP06AE0QsXY0Pp000u0> and that will > be the last you hear from us! We promise! > > 814 Mission Street > 5th Floor > San Francisco, CA 94103 > *T* + 1 415 273 1389 > *F* + 1 415 986 2964 > > twitter <http://engage.thoughtworks.com/a0000n0APQ0Y00tE7DQXupP> > > <http://engage.thoughtworks.com/I0A08QY0nupuQP0P0X0DE00> > > This email was sent to ci...@ki.... If you no longer wish > to receive these emails you may manage your email preferences > <http://engage.thoughtworks.com/u/VYDw000PXA0E000QnuPpaQ0> at any > time. > > -- Dr.-Ing. Reiner Jung, Software Engineering Group Dept. Computer Science, Kiel University, D-24118 Kiel, Germany Tel: +49 (0)431 880-2776, Fax: -7617 Email: rei...@em... http://se.informatik.uni-kiel.de/ |
|
From: Andre v. H. <van...@in...> - 2017-02-07 07:58:19
|
Hi all, disappointing and unexpected news: Snap CI will stop its service. Unfortunately, this means that we need to find an alternative for a staged (and hosted) CD pipeline by Aug 2017, latest. We'll keep you posted. If you have ideas, please do not hesitate to share them. Best, André -------- Forwarded Message -------- Subject: Snap CI is going away Date: Mon, 6 Feb 2017 14:08:43 -0600 (CST) From: Louda from Snap CI <lb...@th...> Reply-To: su...@sn... To: ci...@ki... <http://engage.thoughtworks.com/SD0E0P0Yn0u0QQp0A00XPo2> Hello All, We have some bad news for you today -- we are canceling Snap CI. *Why are we canceling Snap? * While Snap users love the tool, and we truly believe this offers the best hosted CI/CD experience in the market, we have not made the major impact we feel was necessary to continue support of the tool. We are a mission driven company. We are focused on helping our industry improve, think differently, and work differently. The decision is based on the intent to maximize impact on how software is built, therefore we are concentrating our efforts on our open source tool, GoCD. *How long will Snap be available for?* It is our intention to provide Snap CI service for the next 6 months. Initially, we will provide a similar service as we do now - critical bugs will be fixed and support will be provided as before. However, development on new features will be immediately stopped. Support will continue throughout the 6 month period but we do expect to stop the support for new repositories and to limit configuration changes to Snap CI builds to encourage migration to other tools later in the end of life (EOL) period. You can review our visual timeline (see below) for details of the EOL period. *How will you communicate the changes and updates to the EOL timeline for Snap?* We will not remove or change any Snap CI features or support without first informing you. We will continue to inform you of any changes to Snap through this newsletter, our website <http://engage.thoughtworks.com/Q0XE0YD0Q30nP0QAP00pup0>, and in-app notifications. *What happens now? * The most immediate change is that no new users will be allowed to sign up to Snap CI. This will impact you if you want to add new collaborators to Snap CI. You can read more about this in our FAQ <http://engage.thoughtworks.com/Q0XE0YD0Q30nP0QAP00pup0>. We will also stop charging for Snap CI use. Those of you paying monthly will receive no further charges to your credit card and your subscription will be extended for free until after the EOL period is over. Likewise those on invoices will be automatically extended for free. We know that canceling Snap CI is likely to be an inconvenience for you and your teams. We will do our best to make this transition as smooth as possible. We have already provided comprehensive information about the EOL timeline as well as a full FAQ on our website <http://engage.thoughtworks.com/Q0XE0YD0Q30nP0QAP00pup0>. As we add more to this information we will update you. If you have any immediate questions that we have not already covered, please don't hesitate to ask, and of course, you will still have access to our first-class support team at su...@sn... <http://engage.thoughtworks.com/HQ0000P0QpqYXEu0nAD004P>. Finally, we wanted to thank you for being a supporter of Snap CI. We very much appreciate it. - Louda and the Snap team ------------------------------------------------------------------------ EOL Timeline You are receiving this email because you had registered for Snap at https://snap-ci.com <http://engage.thoughtworks.com/tPEp0P0XQY0nr00QDu000A5> at some point in time. This newsletter is a relatively infrequent update that we plan to use to let our users know of the latest happenings in the world of Snap. Our intent is not to spam you, though. If you would like to unsubscribe to this email, just let us know <http://engage.thoughtworks.com/JD0nQP06AE0QsXY0Pp000u0> and that will be the last you hear from us! We promise! 814 Mission Street 5th Floor San Francisco, CA 94103 *T* + 1 415 273 1389 *F* + 1 415 986 2964 twitter <http://engage.thoughtworks.com/a0000n0APQ0Y00tE7DQXupP> <http://engage.thoughtworks.com/I0A08QY0nupuQP0P0X0DE00> This email was sent to ci...@ki.... If you no longer wish to receive these emails you may manage your email preferences <http://engage.thoughtworks.com/u/VYDw000PXA0E000QnuPpaQ0> at any time. -- Dr.-Ing. André van Hoorn Interim Professor (Prof.-Vertr.) University of Stuttgart, Inst. of Software Technology Reliable Software Systems (RSS) Group Universitätsstraße 38, D-70569 Stuttgart, Germany Room: 1.345 Phone: +49 (0)711 685-88-252, Fax: -472 E-Mail: van...@in... http://www.iste.uni-stuttgart.de/rss/people/vanhoorn/ http://kieker-monitoring.net/, http://research.spec.org/ |
|
From: Andre v. H. <van...@in...> - 2017-02-06 08:09:20
|
Hi Christian, many thanks for your efforts and for taking care of the integration! Hopefully we see the plots from the nightly benchmarks soon --- the build seems a bit volatile at present. Best, André On 06.02.2017 08:49, Christian Wulf wrote: > Hi everybody, > > we have just replaced the old monitoring component by the new one, which > has a reduced runtime monitoring overhead of only 17% compared to the > old one (measured with MooBench). While the internal API has undergone a > huge change, the user interface has not changed very much. A writer is > still configurable via the kieker.properties file. However, some writers > have been renamed. Moreover, some configuration options of some writers > have been removed or moved to the WriterController. Details follow with > the official release in this year. > > During this migration, we also changed the minimum Java version from 1.6 > to 1.7. Moreover, we made Kieker more stable by adding more tests and by > fixing concurrent bugs in our available tests. > > For more information, we refer to our paper presented at the SSP 2016 > (http://eprints.uni-kiel.de/34634/) and the 'stable' branch of Kieker > (https://github.com/kieker-monitoring/kieker/tree/stable). > > Bye > Christian > -- Dr.-Ing. André van Hoorn Interim Professor (Prof.-Vertr.) University of Stuttgart, Inst. of Software Technology Reliable Software Systems (RSS) Group Universitätsstraße 38, D-70569 Stuttgart, Germany Room: 1.345 Phone: +49 (0)711 685-88-252, Fax: -472 E-Mail: van...@in... http://www.iste.uni-stuttgart.de/rss/people/vanhoorn/ http://kieker-monitoring.net/, http://research.spec.org/ |
|
From: Christian W. <chr...@em...> - 2017-02-06 07:49:21
|
Hi everybody, we have just replaced the old monitoring component by the new one, which has a reduced runtime monitoring overhead of only 17% compared to the old one (measured with MooBench). While the internal API has undergone a huge change, the user interface has not changed very much. A writer is still configurable via the kieker.properties file. However, some writers have been renamed. Moreover, some configuration options of some writers have been removed or moved to the WriterController. Details follow with the official release in this year. During this migration, we also changed the minimum Java version from 1.6 to 1.7. Moreover, we made Kieker more stable by adding more tests and by fixing concurrent bugs in our available tests. For more information, we refer to our paper presented at the SSP 2016 (http://eprints.uni-kiel.de/34634/) and the 'stable' branch of Kieker (https://github.com/kieker-monitoring/kieker/tree/stable). Bye Christian -- M.Sc. Christian Wulf Research Assistant Software Engineering Group Dept. Computer Science Christian-Albrechts-Platz 4 University of Kiel 24118 Kiel, Germany Room: 1213 Phone: +49 431 880 2776 Fax: +49 431 880 7617 Email: ch...@in... WWW: http://se.informatik.uni-kiel.de/ |
|
From: Reiner J. <rei...@em...> - 2016-12-16 20:12:13
|
Hello Folks, a lot of time has passed (12 month) since the last release of the Kieker Instrumentation Record Language (IRL). Over the last year, we improved the generators to support the new Kieker record API 1.13-SNAPSHOT, added model types [1] as means to extend record types, and modularized the generator. We also moved from Eclipse Mars to Neon and in that process adapted to the new Xtext APIs, as the old ones are becoming deprecated. Unfortunately, the old command line compiler could not make this transition. As it was a hack anyway, it gives us the opportunity to rebuild it as an headless RCP application. As always, we provide a release repository: https://build.se.informatik.uni-kiel.de/eus/mdm/release/1.2 Kind Regards Reiner & Christian -- Reiner Jung, Software Engineering Group Dept. Computer Science, Kiel University, D-24118 Kiel, Germany Tel: +49 (0)431 880-2776, Fax: -7617 Email: rei...@em... http://se.informatik.uni-kiel.de/ |
|
From: Christian W. <chr...@em...> - 2016-11-30 15:36:14
|
Hi everybody, inspired by the work of Aike Sass, Holger Eichelberger et al. (Uni Hildesheim), I adapted the implementation and the R script of MooBench. After two days of work, MooBench now supports logging and displaying the heap memory consumption and the number of garbage collections. We are now able to identify bottlenecks and anomalies in monitoring frameworks caused by a high memory activity and a high GC activity. @Sass et al.: thank you very much! An example plot showing MooBench's TCP writing phase can be found here: https://build.se.informatik.uni-kiel.de/kieker/moobench/raw/master/bin/r/response-time-of-chunks-of-calls.csv-30-November-2016.pdf Note that the PDF contains more than one page. The R script which has generated this PDF is located in the same directory. Just adapt the URL accordingly. The original work of Sass et al. can be found here: https://sdqweb.ipd.kit.edu/typo3/sdq/fileadmin/user_upload/palladio-conference/2016/papers/From_Reproducibility_Problems_to_Improvements__A_journey.pdf Please let me know if you have any issues. Bye Christian -- M.Sc. Christian Wulf Research Assistant Software Engineering Group Dept. Computer Science Christian-Albrechts-Platz 4 University of Kiel 24118 Kiel, Germany Room: 1213 Phone: +49 431 880 2776 Fax: +49 431 880 7617 Email: ch...@in... WWW: http://se.informatik.uni-kiel.de/ |
|
From: Wilhelm (W. H. <has...@em...> - 2016-11-22 13:20:53
|
First International Workshop on Monitoring in Large-Scale Software Systems (MoLS 2017) (http://mevss.jku.at/mols2017) in conjunction with ICPE 2017, the 8th ACM/SPEC International Conference on Performance Engineering April 22-26, 2017, L'Aquila, Italy Organizers: Rick Rabiser (JKU Linz, Austria) Michael Vierhauser (JKU Linz, Austria) Sam Guinea (Polimi, Italy) Wilhelm Hasselbring (CAU Kiel, Germany) == Short description of motivation and goals This workshop aims to explore and explicate the current status and ongoing work on monitoring in large-scale software systems and the transfer of knowledge between different disciplines and domains. A particular goal of the workshop is thus to bring together different communities working on monitoring approaches such as (application) performance and resource monitoring, requirements monitoring, and runtime verification. The workshop also aims at bringing together researchers and practitioners to discuss practical problems vs. potential solutions. Future directions for research will be outlined based on challenges discussed and the needs expressed by the participants. The workshop thus has the following objectives: (i) Discuss how monitoring can be supported in large-scale software systems (state of the art). (ii) Discuss open challenges in research and practice. == Dates Deadline for submissions: Jan 9, 2017 Notification of acceptance: Jan 31, 2017 Camera-ready version due: Feb 8, 2017 Workshop planned for: Apr 23, 2017 == Submissions We are seeking for research papers and experience reports (4-8 pages) as well as position and vision papers (4 pages max) in ACM Proceedings Style (http://www.acm.org/publications/proceedings-template). Submissions will be selected based on the relevance to the workshop topics and the suitability to trigger discussions. Papers should be submitted as PDF files via EasyChair: https://www.easychair.org/conferences/?conf=mols2017 == Program Committee (invited, to be confirmed) Luciano Baresi, Polimi, ITA Thomas Bures, Charles U. Prague, CZE Jane Cleland-Huang, Notre Dame, ID, USA Mads Dam, KTH/CSC, Stockholm, SWE Alexey Fishkin, Siemens CT, Munich, DEU Paul Grünbacher, JKU Linz, AUT Andre van Hoorn, U. of Stuttgart, DEU Christian Inzinger, U. of Zürich, CHE Andrea Janes, Free U. of Bozen-Bolzano, ITA Falko Kötter, Fraunhofer IAO, Stuttgart, DEU Patrick Mäder, TU Ilmenau, DEU Olivier Perrin, Nancy 2 U., FRA Klaus Schmid, U. Hildesheim, DEU Jocelyn Simmonds, U. of Chile, CHL Oleg Sokolsky, U. of Pennsylvania, USA Uwe Zdun, U. Vienna, AUT ... and the workshop organizers == Detailed Motivation Large-scale, heterogeneous software systems such as cyber-physical systems, cloud-based systems, or service-based systems are ubiquitous in many domains. Often, such systems are systems of systems working together to fulfill common goals resulting from domain or customer requirements. Such systems' full behavior emerges only at runtime, when the involved systems interact with each other, with hardware, third-party systems, or legacy systems. Thus, engineers are interested in monitoring the overall system at runtime for instance, to verify components' correct timing or measure performance and resource consumption. Monitoring can happen continuously at runtime, to give instant feedback on behavior violations, or post hoc, on the basis of recorded event traces and data logs. The complexity and heterogeneity of large-scale software systems, however, complicates runtime monitoring. Properties must be checked across the boundaries of multiple constituent systems and heterogeneous, domain-specific technologies must be instrumented. Also, different types of properties must be checked at runtime, including global invariants and exceptions, range checks of variables, temporal constraints on events, or architectural rules constraining component interactions. Finally, systems exist in many different versions and variants owing to the continuous, independent evolution of their constituent systems. Adaption and reconfiguration of monitoring solutions thus becomes essential. This workshop aims to explore and explicate the current status and ongoing work on monitoring in large-scale software systems and the transfer of knowledge between different disciplines and domains. A particular goal of the workshop is thus to bring together different communities working on monitoring approaches such as (application) performance and resource monitoring, requirements monitoring, and runtime verification. The workshop also aims at bringing together researchers and practitioners to discuss practical problems vs. potential solutions. Future directions for research will be outlined based on challenges discussed and the needs expressed by the participants. The workshop thus has the following objectives: (i) Discuss how monitoring can be supported in large-scale software systems (state of the art). (ii) Discuss open challenges in research and practice. ==Topics of interest We particularly encourage research papers based on industrial experience and empirical studies, as well as papers, which identify and structure open challenges and research questions. We are interested in all topics related to monitoring in large-scale soft-ware systems (systems of systems, cloud-based systems, service-oriented systems, big-data systems, business processes, cyber-physical systems, automation production/automotive systems, etc.). This includes, but is not limited to: (o) Requirements monitoring in large-scale systems (o) Runtime verification of large-scale systems (o) Complex event processing in large-scale systems (o) Performance monitoring in large-scale systems (o) Monitoring along the continuum, from the data source to fog- and cloud-based solutions (o) Supporting monitoring in large-scale systems with... (-) Requirements as runtime entities (-) Models at runtime (-) Runtime constraint checking (-) Visualization techniques (-) Human-computer interaction for operators (o) Monitoring as a means to support evo-lution and/or maintenance in large-scale systems (o) Monitoring in the context of DevOps/ continuous deployment/integration (o) Tools and frameworks for monitoring large-scale systems |
|
From: Wilhelm (W. H. <has...@em...> - 2016-10-13 16:57:00
|
Dear Kieker Community, The program of SSP 2016 is online: http://www.performance-symposium.org/2016/program/ For all attendees, registration by Oct. 23, 2016 at the following link is required for entrance allowance to the symposium: https://www.diwish.de/termin/kosse-7th-symposium-on-software-performance-2016.html There is no participation fee for the symposium, but this registration is required such that we can produce name badges etc. Looking forward to meet in Kiel, Willi Hasselbring -- Prof. Dr. W. Hasselbring, Software Engineering Group Dept. Computer Science, Kiel University, D-24118 Kiel, Germany Tel: +49 (0)431 880-4664, -3734 (secretary), Fax: -7617 Email: has...@em... http://se.informatik.uni-kiel.de/ |
|
From: Andre v. H. <van...@in...> - 2016-07-02 01:23:39
|
Hi all, Kieker's Git repository is now "really" hosted on GitHub: https://github.com/kieker-monitoring/kieker (Before, it hosted only the mirrored version from GitLab.) The old GitLab repository is no longer accessible! Recommended practice for contributors is to fork the repository on GitHub, clone and develop in the forked repository, and send a pull request to the Kieker Git via GitHub to request the integration of changes. This triggers the execution of the CI pipeline and a pull request will only be visible/accepted if the pipeline passed. Developers with write permissions to the repository can push to the Kieker repository directly but integration must also be done via a pull request to trigger the execution of the CI pipeline. In any case, please change your repository URL to the new URL (either your forked repository or Kieker's repository) on GitHub. Instructions can be found on https://help.github.com/articles/changing-a-remote-s-url/ We are currently finalizing and documenting the setup. Stay tuned. Best, André -- Dr.-Ing. André van Hoorn Interim Professor (Prof.-Vertr.) University of Stuttgart, Inst. of Software Technology Reliable Software Systems (RSS) Group Universitätsstraße 38, D-70569 Stuttgart, Germany Room: 1.345 Phone: +49 (0)711 685-88-252, Fax: -472 E-Mail: van...@in... http://www.iste.uni-stuttgart.de/rss/people/vanhoorn/ http://kieker-monitoring.net/, http://research.spec.org/ |
|
From: Wilhelm (W. H. <has...@em...> - 2016-06-15 11:47:06
|
Call for Papers
Symposium on Software Performance 2016
Kiel, November 08-09, 2016
http://www.performance-symposium.org/2016/
Performance is one of the most relevant quality attributes of any IT
system. While good performance leads to high user satisfaction, weak
response times lead to loss of users, perceived unavailability of the
system, or unnecessarily high costs of network or computing
resources. Therefore, various techniques to evaluate, control, and
improve the performance of IT systems have been developed, ranging
from online monitoring and benchmarking to modeling and
prediction. Experience shows, that for system design or later
optimization, such techniques should be applied in smart combination.
Therefore, the "Symposium on Software Performance" brings together
researchers and practitioners interested in all facets of software
performance, ranging from modeling and prediction to monitoring and
runtime management. The symposium is organized by the three
established research groups Descartes, Kieker, and Palladio; thus this
symposium also serves as a joint community meeting.
The symposium program will include contributions (in form of talks,
demos, and posters) from practitioners and researchers in the field of
software performance. SSP 2016 is supported by the GI special
interest group "Software-technik" and by the GI special interest
committee "Messung, Modellierung und Bewertung (MMB) von
Rechensystemen".
Submission
We solicit technical papers (maximum 3 pages), extended abstracts for
industry or experience talks (maximum 700 words), and
posters. Submission deadlines are in August 2016, see web pages at
http://www.performance-symposium.org/2016/important_dates/
--
Prof. Dr. W. Hasselbring, Software Engineering Group
Dept. Computer Science, Kiel University, D-24118 Kiel, Germany
Tel: +49 (0)431 880-4664, -3734 (secretary), Fax: -7617
Email: has...@em...
http://se.informatik.uni-kiel.de/
|
|
From: Christian W. <chr...@em...> - 2016-06-08 13:06:55
|
Hi everybody, we have just published our new sub page "Features" on our website where all current features of Kieker are briefly described. The next step is to add a link to each feature description which points to a full description at our confluence page. http://kieker-monitoring.net Bye Christian -- M.Sc. Christian Wulf Research Assistant Software Engineering Group Dept. Computer Science Christian-Albrechts-Platz 4 University of Kiel 24118 Kiel, Germany Room: 1213 Phone: +49 431 880 2776 Fax: +49 431 880 7617 Email: ch...@in... WWW: http://se.informatik.uni-kiel.de/ |
|
From: Andre v. H. <van...@in...> - 2016-04-18 13:24:03
|
Thanks for forwarding, Christian. Same issue as http://trac.kieker-monitoring.net/ticket/1772 I will take care of it this afternoon. Best, André On 18.04.2016 15:09, Christian Wulf wrote: > Hi everybody, > > could somebody answer to the comment on > > http://kieker-monitoring.net/wp-admin/edit-comments.php?p=1112&comment_status=moderated > > Thanks. > > Regards, > Christian > -- Dr.-Ing. André van Hoorn Interim Professor (Prof.-Vertr.) University of Stuttgart, Inst. of Software Technology Reliable Software Systems (RSS) Group Universitätsstraße 38, D-70569 Stuttgart, Germany Room: 1.345 Phone: +49 (0)711 685-88-252, Fax: -472 E-Mail: van...@in... http://www.iste.uni-stuttgart.de/rss/people/vanhoorn/ http://kieker-monitoring.net/, http://research.spec.org/ QUDOS 2016: 2nd International Workshop on Quality-Aware DevOps Saarbrücken, Germany, July 21, 2016, co-located with ISSTA 2016 http://qudos2016.fortiss.org/ (Submission deadline April 22, 2016) |
|
From: Christian W. <chr...@em...> - 2016-04-18 13:09:33
|
Hi everybody, could somebody answer to the comment on http://kieker-monitoring.net/wp-admin/edit-comments.php?p=1112&comment_status=moderated Thanks. Regards, Christian -- M.Sc. Christian Wulf Research Assistant Software Engineering Group Dept. Computer Science Christian-Albrechts-Platz 4 University of Kiel 24118 Kiel, Germany Room: 1213 Phone: +49 431 880 2776 Fax: +49 431 880 7617 Email: ch...@in... WWW: http://se.informatik.uni-kiel.de/ |