Menu
▾
▴
wrapper-user — User issues for Wrapper. (Support questions, etc.)
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(13) |
Nov
(16) |
Dec
(29) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(38) |
Feb
(51) |
Mar
(51) |
Apr
(115) |
May
(82) |
Jun
(30) |
Jul
(50) |
Aug
(68) |
Sep
(57) |
Oct
(160) |
Nov
(80) |
Dec
(78) |
| 2004 |
Jan
(71) |
Feb
(75) |
Mar
(108) |
Apr
(87) |
May
(79) |
Jun
(70) |
Jul
(69) |
Aug
(39) |
Sep
(52) |
Oct
(47) |
Nov
(50) |
Dec
(32) |
| 2005 |
Jan
(22) |
Feb
(122) |
Mar
(46) |
Apr
(76) |
May
(31) |
Jun
(51) |
Jul
(61) |
Aug
(70) |
Sep
(37) |
Oct
(46) |
Nov
(57) |
Dec
(83) |
| 2006 |
Jan
(55) |
Feb
(81) |
Mar
(51) |
Apr
(67) |
May
(77) |
Jun
(43) |
Jul
(106) |
Aug
(64) |
Sep
(47) |
Oct
(64) |
Nov
(60) |
Dec
(12) |
| 2007 |
Jan
(50) |
Feb
(93) |
Mar
(49) |
Apr
(56) |
May
(40) |
Jun
(63) |
Jul
(40) |
Aug
(47) |
Sep
(54) |
Oct
(37) |
Nov
(54) |
Dec
(37) |
| 2008 |
Jan
(35) |
Feb
(39) |
Mar
(26) |
Apr
(14) |
May
(23) |
Jun
(51) |
Jul
(43) |
Aug
(26) |
Sep
(29) |
Oct
(31) |
Nov
(24) |
Dec
(16) |
| 2009 |
Jan
(21) |
Feb
(30) |
Mar
(74) |
Apr
(26) |
May
(26) |
Jun
(43) |
Jul
(23) |
Aug
(23) |
Sep
(15) |
Oct
(27) |
Nov
(37) |
Dec
(10) |
| 2010 |
Jan
(16) |
Feb
(28) |
Mar
(16) |
Apr
(45) |
May
(8) |
Jun
(68) |
Jul
(45) |
Aug
(44) |
Sep
(51) |
Oct
(7) |
Nov
(20) |
Dec
(21) |
| 2011 |
Jan
(14) |
Feb
(17) |
Mar
(7) |
Apr
(7) |
May
(48) |
Jun
(23) |
Jul
(5) |
Aug
(33) |
Sep
(22) |
Oct
(14) |
Nov
(14) |
Dec
(5) |
| 2012 |
Jan
|
Feb
(10) |
Mar
(12) |
Apr
(51) |
May
(10) |
Jun
(8) |
Jul
(14) |
Aug
(22) |
Sep
(9) |
Oct
(24) |
Nov
(14) |
Dec
(13) |
| 2013 |
Jan
(12) |
Feb
(4) |
Mar
(14) |
Apr
(19) |
May
(2) |
Jun
(5) |
Jul
(13) |
Aug
(10) |
Sep
(4) |
Oct
(11) |
Nov
(13) |
Dec
(2) |
| 2014 |
Jan
(3) |
Feb
(14) |
Mar
(5) |
Apr
(10) |
May
(10) |
Jun
(11) |
Jul
(10) |
Aug
(3) |
Sep
(13) |
Oct
(22) |
Nov
(14) |
Dec
(32) |
| 2015 |
Jan
(8) |
Feb
(2) |
Mar
(17) |
Apr
(1) |
May
(24) |
Jun
|
Jul
(4) |
Aug
|
Sep
(9) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
| 2016 |
Jan
(8) |
Feb
(6) |
Mar
(6) |
Apr
(9) |
May
(3) |
Jun
(2) |
Jul
(7) |
Aug
(6) |
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
| 2017 |
Jan
(9) |
Feb
(8) |
Mar
(6) |
Apr
|
May
|
Jun
(3) |
Jul
(13) |
Aug
(10) |
Sep
(8) |
Oct
|
Nov
(6) |
Dec
|
| 2018 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
(2) |
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
(9) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2019 |
Jan
(9) |
Feb
|
Mar
|
Apr
(10) |
May
(3) |
Jun
|
Jul
(7) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2020 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2021 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2023 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Alexandre K. <ale...@ta...> - 2015-03-03 03:59:03
|
Hi Greg, I'm sorry for the trouble. What is the value of "args" when you execute: WrapperManager.start( new Main(), args ); Can you show me the content of wrapper.conf? If there is sensitive data, please send it to su...@ta... Which command do you use to start the Wrapper using the wrapper executable? Regards, Alexandre Klein Tanuki Software, Ltd. 6-16-7-1001 Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel: +81-3-3878-3211 Fax: +81-3-3878-0313 http://www.tanukisoftware.com On Tue, Mar 3, 2015 at 10:01 AM, Greg Rivera <gre...@gm...> wrote: > Has anyone gotten a chance to look at this yet? i still have not been able > to figure out why this is happening. > > On Wed, Feb 25, 2015 at 1:05 PM, Greg Rivera <gre...@gm...> > wrote: > >> I have subscribed to the mailing list and am resending my query. >> >> Thank you. >> >> On Wed, Feb 25, 2015 at 1:03 PM, Greg Rivera <gre...@gm...> >> wrote: >> >>> Hello, >>> >>> I am using method integration 3. >>> >>> I have asked a question here: >>> >>> http://stackoverflow.com/questions/28709609/where-does-wrappermanager-look-for-the-wrapper-conf-file-in-eclipse >>> >>> The contents of this question are below: >>> >>> I have this line in my main function >>> >>> WrapperManager.start( new Main(), args ); >>> >>> When I debug the Main class as a java app, I am able to break at this >>> line. However when I do in my expressions window >>> >>> WrapperManager.getProperties(); >>> >>> it returns empty meaning my wrapper.conf file was not found. For output >>> I get the following: >>> >>> WrapperManager: Initializing...WrapperManager: WARNING - The wrapper.native_library system property was notWrapperManager: set. Using the default value, 'wrapper'.WrapperManager: WARNING - The version of the Wrapper which launched this JVM isWrapperManager: "unknown" while the version of the native libraryWrapperManager: is "3.5.26".WrapperManager: The Wrapper may appear to work correctly but some features mayWrapperManager: not function correctly. This configuration has not been testedWrapperManager: and is not supported.WrapperManager: >>> >>> If someone could please tell me where WrapperManager is looking for this >>> file that would be great. I added wrapper.jar to the build path and to the >>> debug configuration but still I could not get this to work. >>> >>> I looked at the following site: >>> http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html#mainClass >>> >>> However after explaining the main class it does not say how I should be >>> running it. I use the wrapper executable and it says my main is already >>> running the service wrapper. I debug using eclipse and the service wrapper >>> gives the info above. >>> >>> Thanks >>> >>> Info about my env: Linux xxxx-xxxx 3.13.0-45-generic #74-Ubuntu SMP Tue >>> Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> >>> wrapper version Java Service Wrapper Community Edition 64-bit 3.5.26 >>> Copyright (C) 1999-2014 Tanuki Software, Ltd. All Rights Reserved. >>> http://wrapper.tanukisoftware.com >>> >>> -- >>> Greg Louis Rivera >>> UCLA | Class of 2013 | B.S. Computer Science >>> Telescope Inc. | Java Developer >>> (805) 844 9209 | gre...@gm... >>> >>> >> >> >> -- >> Greg Louis Rivera >> UCLA | Class of 2013 | B.S. Computer Science >> Telescope Inc. | Java Developer >> (805) 844 9209 | gre...@gm... >> >> > > > -- > Greg Louis Rivera > UCLA | Class of 2013 | B.S. Computer Science > Telescope Inc. | Java Developer > (805) 844 9209 | gre...@gm... > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Greg R. <gre...@gm...> - 2015-03-03 01:01:41
|
Has anyone gotten a chance to look at this yet? i still have not been able to figure out why this is happening. On Wed, Feb 25, 2015 at 1:05 PM, Greg Rivera <gre...@gm...> wrote: > I have subscribed to the mailing list and am resending my query. > > Thank you. > > On Wed, Feb 25, 2015 at 1:03 PM, Greg Rivera <gre...@gm...> > wrote: > >> Hello, >> >> I am using method integration 3. >> >> I have asked a question here: >> >> http://stackoverflow.com/questions/28709609/where-does-wrappermanager-look-for-the-wrapper-conf-file-in-eclipse >> >> The contents of this question are below: >> >> I have this line in my main function >> >> WrapperManager.start( new Main(), args ); >> >> When I debug the Main class as a java app, I am able to break at this >> line. However when I do in my expressions window >> >> WrapperManager.getProperties(); >> >> it returns empty meaning my wrapper.conf file was not found. For output I >> get the following: >> >> WrapperManager: Initializing...WrapperManager: WARNING - The wrapper.native_library system property was notWrapperManager: set. Using the default value, 'wrapper'.WrapperManager: WARNING - The version of the Wrapper which launched this JVM isWrapperManager: "unknown" while the version of the native libraryWrapperManager: is "3.5.26".WrapperManager: The Wrapper may appear to work correctly but some features mayWrapperManager: not function correctly. This configuration has not been testedWrapperManager: and is not supported.WrapperManager: >> >> If someone could please tell me where WrapperManager is looking for this >> file that would be great. I added wrapper.jar to the build path and to the >> debug configuration but still I could not get this to work. >> >> I looked at the following site: >> http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html#mainClass >> >> However after explaining the main class it does not say how I should be >> running it. I use the wrapper executable and it says my main is already >> running the service wrapper. I debug using eclipse and the service wrapper >> gives the info above. >> >> Thanks >> >> Info about my env: Linux xxxx-xxxx 3.13.0-45-generic #74-Ubuntu SMP Tue >> Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> wrapper version Java Service Wrapper Community Edition 64-bit 3.5.26 >> Copyright (C) 1999-2014 Tanuki Software, Ltd. All Rights Reserved. >> http://wrapper.tanukisoftware.com >> >> -- >> Greg Louis Rivera >> UCLA | Class of 2013 | B.S. Computer Science >> Telescope Inc. | Java Developer >> (805) 844 9209 | gre...@gm... >> >> > > > -- > Greg Louis Rivera > UCLA | Class of 2013 | B.S. Computer Science > Telescope Inc. | Java Developer > (805) 844 9209 | gre...@gm... > > -- Greg Louis Rivera UCLA | Class of 2013 | B.S. Computer Science Telescope Inc. | Java Developer (805) 844 9209 | gre...@gm... |
|
From: Greg R. <gre...@gm...> - 2015-02-25 21:05:11
|
I have subscribed to the mailing list and am resending my query. Thank you. On Wed, Feb 25, 2015 at 1:03 PM, Greg Rivera <gre...@gm...> wrote: > Hello, > > I am using method integration 3. > > I have asked a question here: > > http://stackoverflow.com/questions/28709609/where-does-wrappermanager-look-for-the-wrapper-conf-file-in-eclipse > > The contents of this question are below: > > I have this line in my main function > > WrapperManager.start( new Main(), args ); > > When I debug the Main class as a java app, I am able to break at this > line. However when I do in my expressions window > > WrapperManager.getProperties(); > > it returns empty meaning my wrapper.conf file was not found. For output I > get the following: > > WrapperManager: Initializing...WrapperManager: WARNING - The wrapper.native_library system property was notWrapperManager: set. Using the default value, 'wrapper'.WrapperManager: WARNING - The version of the Wrapper which launched this JVM isWrapperManager: "unknown" while the version of the native libraryWrapperManager: is "3.5.26".WrapperManager: The Wrapper may appear to work correctly but some features mayWrapperManager: not function correctly. This configuration has not been testedWrapperManager: and is not supported.WrapperManager: > > If someone could please tell me where WrapperManager is looking for this > file that would be great. I added wrapper.jar to the build path and to the > debug configuration but still I could not get this to work. > > I looked at the following site: > http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html#mainClass > > However after explaining the main class it does not say how I should be > running it. I use the wrapper executable and it says my main is already > running the service wrapper. I debug using eclipse and the service wrapper > gives the info above. > > Thanks > > Info about my env: Linux xxxx-xxxx 3.13.0-45-generic #74-Ubuntu SMP Tue > Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > wrapper version Java Service Wrapper Community Edition 64-bit 3.5.26 > Copyright (C) 1999-2014 Tanuki Software, Ltd. All Rights Reserved. > http://wrapper.tanukisoftware.com > > -- > Greg Louis Rivera > UCLA | Class of 2013 | B.S. Computer Science > Telescope Inc. | Java Developer > (805) 844 9209 | gre...@gm... > > -- Greg Louis Rivera UCLA | Class of 2013 | B.S. Computer Science Telescope Inc. | Java Developer (805) 844 9209 | gre...@gm... |
|
From: Jeff N. <je...@ci...> - 2015-02-24 03:08:52
|
Hi All, ConcourseDB <https://github.com/cinchapi/concourse> is an open source project that uses the community edition of the wrapper. Concourse uses the MIT licenses because we don't want to force commercial users of the database to licenses their code under a certain license. Since we ship the wrapper with the database to start/stop the server, should we be releasing under GPLv2? I'm not sure if our usage constitutes a derivative work, so I wanted to clarify. Thanks, Jeff *Jeff Nelson* Cinchapi Software Collective je...@ci... | 470.377.1717 github.com/cinchapi | twitter.com/cinchapi |
|
From: Tu T. N. <ttn...@ra...> - 2015-01-26 22:02:54
|
Hello Alexandre, I think I am close to figuring out this issue. If I could get a little advice from you. I think this issue has to do with excessive logging from the application. In 3 (out of 3 that I have looked into ) instances where we see this CPU time message, the logges are filled with 800 or more lines of logging in the exact second the message happens. To support this, there was a time when the logging was not configured and the app ran 50 days without an issue. Do you think this amount of logging may cause the CPU time issue/message? Also. For the logging level, it was set to “WARNING”, when the actual level should be “WARN”. I see debug and info message in the log that should not be there. Can you confirm that “WARNING” is not a valid setting? Regards, Tu Nguyen | FTPC Support Engineer | Office: 408.271.3464 | Mobile: 408.464.3252 | Rockwell Automation | Mission Viejo, CA (GMT -8) From: Alexandre Klein [mailto:ale...@ta...] Sent: Wednesday, October 01, 2014 10:54 PM To: wra...@li... Cc: Elaine M. Julius Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds" Tu, Since version 3.2.3, the Wrapper has evolved a lot. Please take a look at the release notes which contains all bug fixes and new features for the Java Service Wrapper. http://wrapper.tanukisoftware.com/doc/english/release-notes.html As you can see, the list is long. Here are some changes that might resolve your issue: - we have fixed memory leaks - we have improved the way to write large amounts of output (otherwise the Wrapper thought the JVM was frozen) - we have fixed heap corruption - we have improved the way the Java side of the Wrapper behaves when the Wrapper fails to ping the JVM for an extended period of time. (This was causing problems on systems which were heavily IO bound because the Wrapper could block for a while while trying to write to the log file and the JVM was exiting) As Leif mentioned, we haven't received any log file. Can you send it to: su...@ta...<mailto:su...@ta...> We would be happy to have a look. If possible, please send us the configuration file (wrapper.conf) as well. Regards, Alexandre Klein Alexandre Klein Tanuki Software, Ltd. 6-16-7-1001 Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel: +81-3-3878-3211 Fax: +81-3-3878-0313 http://www.tanukisoftware.com<http://www.tanukisoftware.com/> On Thu, Oct 2, 2014 at 9:21 AM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote: What we are looking for is some justification that we can give our customer that upgrading even might resolve the issue they are seeing. Based on what you see in the logs, is there anything that would point to an upgrade being likely to resolve the problem? From: Leif Mortenson [mailto:lei...@ta...<mailto:lei...@ta...>] Sent: Wednesday, October 01, 2014 6:33 AM To: Wrapper User List Cc: Elaine M. Julius Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds" Tu, Is the machine you are running on a physical or a virtual machine? We have seen cases where a loaded host causes the VM to freeze up when the guest itself does not show any load. 3.2.3 is also a VERY old version of the Wrapper. There have been a lot of improvements over the years in this area. Please try 3.5.25 and see how that works for you. You mentioned log files, but there was nothing attached to your mail. Cheers, Leif On Wed, Oct 1, 2014 at 10:23 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote: Hello, I have an issue where the wrapper restarts the JVM multiple times a day. We are using version 3.2.3 on Windows 2003 SP2. The duration always varies. We checked the CPU usage and its always very little when this happens . We have about 6 services that use the wrapper on this machine and they restart at different times. The suggestion is that if there was a CPU bottle neck they would all have this error at the same time. We also have other sites which use the same configuration but do not have this problem. We have collected logs with wrapper debugging enabled. Please have a look, any help would be much appreciated! Thank you, ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Wrapper-user mailing list Wra...@li...<mailto:Wra...@li...> https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Tu T. N. <ttn...@ra...> - 2015-01-26 22:02:14
|
There is a 100KB restriction on updates. I’m sending the log in a zip.
Your mail to 'Wrapper-user' with the subject
RE: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"
Is being held until the list moderator can review it for approval.
The reason it is being held:
Message body is too big: 206993 bytes with a limit of 100 KB
Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL:
https://lists.sourceforge.net/lists/confirm/wrapper-user/2f3d726f66ced27237fcde0879a514eed9898257
From: Tu T. Nguyen
Sent: Monday, January 26, 2015 1:46 PM
To: 'wra...@li...'
Cc: Elaine M. Julius
Subject: RE: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"
Hello Alexandre,
Sorry I should have included some details with my last email.
Attached is a log segment of one of the single seconds I mentioned. You can see that its 854 lines of logging.
An interesting note is that there are 2 separate TIME (there is only 1 date shown) stamps. The first one (left most) shows the same time down to the second throughout. But if you look at the 2nd time that follows, it spans 11:51:05,269 to 11:57:24,863. This corresponds with the message
INFO | wrapper | 2015/01/12 11:57:24 | Wrapper Process has not received any CPU time for 347 seconds. Extending timeouts.
Which is the roughly the duration of this span of time.
So upon further investigation, the question is asked, was the wrapper hung or storing these messages between 11:51:05,269 to 11:57:24,863 and then finally wrote them out at 11:57:24 ?
Regards,
Tu Nguyen | FTPC Support Engineer | Office: 408.271.3464 | Mobile: 408.464.3252 | Rockwell Automation | Mission Viejo, CA (GMT -8)
From: Tu T. Nguyen
Sent: Monday, January 26, 2015 11:29 AM
To: wra...@li...<mailto:wra...@li...>
Cc: Elaine M. Julius
Subject: RE: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"
Hello Alexandre,
I think I am close to figuring out this issue. If I could get a little advice from you.
I think this issue has to do with excessive logging from the application.
In 3 (out of 3 that I have looked into ) instances where we see this CPU time message, the logges are filled with 800 or more lines of logging in the exact second the message happens.
To support this, there was a time when the logging was not configured and the app ran 50 days without an issue.
Do you think this amount of logging may cause the CPU time issue/message?
Also. For the logging level, it was set to “WARNING”, when the actual level should be “WARN”. I see debug and info message in the log that should not be there. Can you confirm that “WARNING” is not a valid setting?
Regards,
Tu Nguyen | FTPC Support Engineer | Office: 408.271.3464 | Mobile: 408.464.3252 | Rockwell Automation | Mission Viejo, CA (GMT -8)
From: Alexandre Klein [mailto:ale...@ta...]
Sent: Wednesday, October 01, 2014 10:54 PM
To: wra...@li...<mailto:wra...@li...>
Cc: Elaine M. Julius
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"
Tu,
Since version 3.2.3, the Wrapper has evolved a lot.
Please take a look at the release notes which contains all bug fixes and new features for the Java Service Wrapper.
http://wrapper.tanukisoftware.com/doc/english/release-notes.html
As you can see, the list is long. Here are some changes that might resolve your issue:
- we have fixed memory leaks
- we have improved the way to write large amounts of output (otherwise the Wrapper thought the JVM was frozen)
- we have fixed heap corruption
- we have improved the way the Java side of the Wrapper behaves when the Wrapper fails to ping the JVM for an extended period of time. (This was causing problems on systems which were heavily IO bound because the Wrapper could block for a while while trying to write to the log file and the JVM was exiting)
As Leif mentioned, we haven't received any log file.
Can you send it to: su...@ta...<mailto:su...@ta...>
We would be happy to have a look. If possible, please send us the configuration file (wrapper.conf) as well.
Regards,
Alexandre Klein
Alexandre Klein
Tanuki Software, Ltd.
6-16-7-1001 Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel: +81-3-3878-3211
Fax: +81-3-3878-0313
http://www.tanukisoftware.com<http://www.tanukisoftware.com/>
On Thu, Oct 2, 2014 at 9:21 AM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:
What we are looking for is some justification that we can give our customer that upgrading even might resolve the issue they are seeing.
Based on what you see in the logs, is there anything that would point to an upgrade being likely to resolve the problem?
From: Leif Mortenson [mailto:lei...@ta...<mailto:lei...@ta...>]
Sent: Wednesday, October 01, 2014 6:33 AM
To: Wrapper User List
Cc: Elaine M. Julius
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"
Tu,
Is the machine you are running on a physical or a virtual machine? We have seen cases where a loaded host causes the VM to freeze up when the guest itself does not show any load.
3.2.3 is also a VERY old version of the Wrapper. There have been a lot of improvements over the years in this area. Please try 3.5.25 and see how that works for you.
You mentioned log files, but there was nothing attached to your mail.
Cheers,
Leif
On Wed, Oct 1, 2014 at 10:23 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:
Hello,
I have an issue where the wrapper restarts the JVM multiple times a day. We are using version 3.2.3 on Windows 2003 SP2. The duration always varies. We checked the CPU usage and its always very little when this happens . We have about 6 services that use the wrapper on this machine and they restart at different times. The suggestion is that if there was a CPU bottle neck they would all have this error at the same time. We also have other sites which use the same configuration but do not have this problem.
We have collected logs with wrapper debugging enabled. Please have a look, any help would be much appreciated!
Thank you,
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user
|
|
From: Tu T. N. <ttn...@ra...> - 2015-01-26 21:46:09
|
INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:05,269 DEBUG [Timer-3] ChangePriorityWorkflow:187 - ChangePriorityWorkFlow::getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:05,269 INFO [Timer-3] FelsomatDBDevice:377 - queryBasketInformation - list.size() = 9 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:05,629 DEBUG [Timer-1] ChangePriorityWorkflow:187 - ChangePriorityWorkFlow::getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:05,629 INFO [Timer-1] FelsomatDBDevice:377 - queryBasketInformation - list.size() = 9 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:08,363 DEBUG [Thread-4075] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:08,363 DEBUG [Thread-4075] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR3@RNA://$Global/TBCAT/FPI - 30957189 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:08,363 DEBUG [Thread-4075] OPCDataProviderDyn:295 - ::DB2011.DBW4004:INT::1::null::192::Mon Jan 12 11:51:08 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:08,363 DEBUG [pool-2-thread-150] DHRDevice:121 - DHR Trigger received for DHR3@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:08,363 DEBUG [pool-2-thread-150] DHRDevice:125 - Reading DHR for DHR3@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:08,363 DEBUG [pool-2-thread-150] OPCDataProviderDyn:354 - Read DHR data for: DHR3@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:08,910 DEBUG [Timer-4] ChangePriorityWorkflow:187 - ChangePriorityWorkFlow::getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:08,910 INFO [Timer-4] FelsomatDBDevice:377 - queryBasketInformation - list.size() = 9 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:09,519 DEBUG [Timer-2] ChangePriorityWorkflow:187 - ChangePriorityWorkFlow::getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:09,519 INFO [Timer-2] FelsomatDBDevice:377 - queryBasketInformation - list.size() = 9 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:10,129 DEBUG [pool-2-thread-150] DHRDevice:127 - Finished reading DHR for DHR3@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:10,129 INFO [pool-2-thread-150] AutomationLineDhrWorkflow:60 - Handle DHR (DHR3@RNA://$Global/TBCAT/FPI) INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:10,129 DEBUG [pool-2-thread-150] AutomationLineDhrWorkflow:62 - Storing DHR and backflush for DHR3@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:11,504 DEBUG [pool-79-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: declareScrap INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:11,504 DEBUG [pool-79-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@1958f4e INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:11,504 DEBUG [pool-79-thread-1] ProxyServer:76 - arguments.length = 3 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:11,504 DEBUG [pool-79-thread-1] ProxyServer:84 - argument-class: java.lang.String, value = EMCHM-11 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:11,504 DEBUG [pool-79-thread-1] ProxyServer:84 - argument-class: java.lang.Integer, value = 998 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:11,504 DEBUG [pool-79-thread-1] ProxyServer:84 - argument-class: java.lang.String, value = INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:11,504 DEBUG [pool-79-thread-1] DeclareScrapWorkflow:53 - DeclareScrap INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:12,644 DEBUG [Timer-6] ChangePriorityWorkflow:187 - ChangePriorityWorkFlow::getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:12,644 INFO [Timer-6] FelsomatDBDevice:377 - queryBasketInformation - list.size() = 9 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:12,660 DEBUG [Timer-8] ChangePriorityWorkflow:187 - ChangePriorityWorkFlow::getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:12,676 INFO [Timer-8] FelsomatDBDevice:377 - queryBasketInformation - list.size() = 9 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:14,379 DEBUG [Thread-4076] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:14,379 DEBUG [Thread-4076] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/FPI - 24112869 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:14,379 DEBUG [Thread-4076] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::1::null::192::Mon Jan 12 11:51:14 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:14,379 DEBUG [pool-2-thread-149] DHRDevice:121 - DHR Trigger received for DHR2@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:14,379 DEBUG [pool-2-thread-149] DHRDevice:125 - Reading DHR for DHR2@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:14,379 DEBUG [pool-2-thread-149] OPCDataProviderDyn:354 - Read DHR data for: DHR2@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:15,629 DEBUG [Thread-4077] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:15,629 DEBUG [Thread-4077] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/LINISH - 22760265 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:15,629 DEBUG [Thread-4077] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::1::null::192::Mon Jan 12 11:51:15 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:15,629 DEBUG [pool-2-thread-148] DHRDevice:121 - DHR Trigger received for DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:15,629 DEBUG [pool-2-thread-148] DHRDevice:125 - Reading DHR for DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:15,629 DEBUG [pool-2-thread-148] OPCDataProviderDyn:354 - Read DHR data for: DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:16,004 DEBUG [pool-2-thread-149] DHRDevice:127 - Finished reading DHR for DHR2@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:17,097 DEBUG [pool-2-thread-148] DHRDevice:127 - Finished reading DHR for DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:17,176 DEBUG [Timer-5] ChangePriorityWorkflow:187 - ChangePriorityWorkFlow::getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:17,176 INFO [Timer-5] FelsomatDBDevice:377 - queryBasketInformation - list.size() = 9 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:21,769 DEBUG [Timer-7] ChangePriorityWorkflow:187 - ChangePriorityWorkFlow::getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:21,816 INFO [Timer-7] FelsomatDBDevice:377 - queryBasketInformation - list.size() = 9 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:29,816 DEBUG [Timer-9] ChangePriorityWorkflow:187 - ChangePriorityWorkFlow::getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:29,816 INFO [Timer-9] FelsomatDBDevice:377 - queryBasketInformation - list.size() = 9 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,269 DEBUG [pool-76-thread-2] ProxyServer:73 - RemoteInvokationProcessor: Method is: deleteObserver INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,269 DEBUG [pool-76-thread-2] ProxyServer:74 - arguments: [Ljava.lang.Object;@1dbb9dc INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,269 DEBUG [pool-76-thread-2] ProxyServer:76 - arguments.length = 1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,269 DEBUG [pool-76-thread-2] ProxyServer:82 - argument is null INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,269 INFO [pool-76-thread-2] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,316 INFO [pool-5-thread-43] CommandListenerActivity:63 - Processing message from command queue. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,316 INFO [pool-5-thread-43] CommandListenerActivity:72 - Processing request of type NewProxyServerRequest INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,332 INFO [pool-5-thread-43] ProxyServer:152 - Proxy server for UnloadBatchWorkflow up and running. Sending response. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,363 DEBUG [pool-80-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: toString INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,363 DEBUG [pool-80-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@ebc282 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,363 DEBUG [pool-80-thread-1] ProxyServer:76 - arguments.length = 0 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,363 INFO [pool-80-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,394 INFO [pool-5-thread-43] CommandListenerActivity:63 - Processing message from command queue. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,394 INFO [pool-5-thread-43] CommandListenerActivity:72 - Processing request of type NewProxyServerRequest INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,410 INFO [pool-5-thread-43] ProxyServer:152 - Proxy server for NotificationWorkflow up and running. Sending response. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,426 DEBUG [pool-81-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: toString INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,426 DEBUG [pool-81-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@1873bf2 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,426 DEBUG [pool-81-thread-1] ProxyServer:76 - arguments.length = 0 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,426 INFO [pool-81-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,426 DEBUG [pool-80-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: addObserver INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,426 DEBUG [pool-80-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@3fdc80 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,426 DEBUG [pool-80-thread-1] ProxyServer:76 - arguments.length = 1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,426 DEBUG [pool-80-thread-1] ProxyServer:82 - argument is null INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,426 INFO [pool-80-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,441 DEBUG [pool-80-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,441 DEBUG [pool-80-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@12 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,441 DEBUG [pool-80-thread-1] ProxyServer:76 - arguments.length = 0 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:35,441 DEBUG [pool-80-thread-1] UnloadBatchWorkflow:176 - entering getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:41,379 DEBUG [Thread-4078] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:41,379 DEBUG [Thread-4078] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR1@RNA://$Global/TBCAT/GRIDBLAST - 6767312 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:41,379 DEBUG [Thread-4078] OPCDataProviderDyn:295 - ::DB2011.DBW2044:INT::1::null::192::Mon Jan 12 11:51:41 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:41,379 DEBUG [pool-2-thread-151] DHRDevice:121 - DHR Trigger received for DHR1@RNA://$Global/TBCAT/GRIDBLAST INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:41,379 DEBUG [pool-2-thread-151] DHRDevice:125 - Reading DHR for DHR1@RNA://$Global/TBCAT/GRIDBLAST INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:41,379 DEBUG [pool-2-thread-151] OPCDataProviderDyn:354 - Read DHR data for: DHR1@RNA://$Global/TBCAT/GRIDBLAST INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:42,535 DEBUG [pool-2-thread-151] DHRDevice:127 - Finished reading DHR for DHR1@RNA://$Global/TBCAT/GRIDBLAST INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:43,941 DEBUG [pool-79-thread-2] ProxyServer:73 - RemoteInvokationProcessor: Method is: deleteObserver INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:43,941 DEBUG [pool-79-thread-2] ProxyServer:74 - arguments: [Ljava.lang.Object;@1e55b94 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:43,941 DEBUG [pool-79-thread-2] ProxyServer:76 - arguments.length = 1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:43,941 DEBUG [pool-79-thread-2] ProxyServer:82 - argument is null INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:43,941 INFO [pool-79-thread-2] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,222 INFO [pool-5-thread-43] CommandListenerActivity:63 - Processing message from command queue. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,222 INFO [pool-5-thread-43] CommandListenerActivity:72 - Processing request of type NewProxyServerRequest INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,222 INFO [pool-5-thread-43] ProxyServer:152 - Proxy server for OverviewWorkflow up and running. Sending response. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,254 DEBUG [pool-82-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: toString INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,254 DEBUG [pool-82-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@1bfeb85 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,254 DEBUG [pool-82-thread-1] ProxyServer:76 - arguments.length = 0 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,254 INFO [pool-82-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,254 DEBUG [pool-82-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: addObserver INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,254 DEBUG [pool-82-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@6b6022 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,254 DEBUG [pool-82-thread-1] ProxyServer:76 - arguments.length = 1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,254 DEBUG [pool-82-thread-1] ProxyServer:82 - argument is null INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,254 INFO [pool-82-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,269 DEBUG [pool-82-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,269 DEBUG [pool-82-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@dcd212 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,269 DEBUG [pool-82-thread-1] ProxyServer:76 - arguments.length = 0 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,269 INFO [pool-82-thread-1] OverviewWorkflow:117 - entering getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,269 DEBUG [pool-82-thread-1] OverviewWorkflow:118 - getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,269 INFO [pool-82-thread-1] OverviewWorkflow:130 - leaving getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:44,269 INFO [pool-82-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:51,394 DEBUG [Thread-4080] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:51,394 DEBUG [Thread-4080] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/FORM - 15915821 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:51,394 DEBUG [Thread-4080] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::1::null::192::Mon Jan 12 11:51:51 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:51,394 DEBUG [pool-2-thread-152] DHRDevice:121 - DHR Trigger received for DHR2@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:51,394 DEBUG [pool-2-thread-152] DHRDevice:125 - Reading DHR for DHR2@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:51,394 DEBUG [pool-2-thread-152] OPCDataProviderDyn:354 - Read DHR data for: DHR2@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:51:53,129 DEBUG [pool-2-thread-152] DHRDevice:127 - Finished reading DHR for DHR2@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:00,660 DEBUG [Thread-4081] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:00,660 DEBUG [Thread-4081] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR1@RNA://$Global/TBCAT/FORM - 12506312 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:00,660 DEBUG [Thread-4081] OPCDataProviderDyn:295 - ::DB2011.DBW2044:INT::1::null::192::Mon Jan 12 11:52:00 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:00,660 DEBUG [pool-2-thread-153] DHRDevice:121 - DHR Trigger received for DHR1@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:00,660 DEBUG [pool-2-thread-153] DHRDevice:125 - Reading DHR for DHR1@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:00,660 DEBUG [pool-2-thread-153] OPCDataProviderDyn:354 - Read DHR data for: DHR1@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:01,879 DEBUG [pool-2-thread-153] DHRDevice:127 - Finished reading DHR for DHR1@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,051 DEBUG [pool-80-thread-2] ProxyServer:73 - RemoteInvokationProcessor: Method is: deleteObserver INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,051 DEBUG [pool-80-thread-2] ProxyServer:74 - arguments: [Ljava.lang.Object;@6ade0f INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,051 DEBUG [pool-80-thread-2] ProxyServer:76 - arguments.length = 1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,051 DEBUG [pool-80-thread-2] ProxyServer:82 - argument is null INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,051 INFO [pool-80-thread-2] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,191 INFO [pool-5-thread-43] CommandListenerActivity:63 - Processing message from command queue. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,191 INFO [pool-5-thread-43] CommandListenerActivity:72 - Processing request of type NewProxyServerRequest INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,191 INFO [pool-5-thread-43] ProxyServer:152 - Proxy server for OverviewWorkflow up and running. Sending response. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,222 DEBUG [pool-83-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: toString INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,222 DEBUG [pool-83-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@150d41 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,222 DEBUG [pool-83-thread-1] ProxyServer:76 - arguments.length = 0 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,222 INFO [pool-83-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,222 DEBUG [pool-83-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: addObserver INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,222 DEBUG [pool-83-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@108704b INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,222 DEBUG [pool-83-thread-1] ProxyServer:76 - arguments.length = 1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,222 DEBUG [pool-83-thread-1] ProxyServer:82 - argument is null INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,222 INFO [pool-83-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,238 DEBUG [pool-83-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,238 DEBUG [pool-83-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@136b039 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,238 DEBUG [pool-83-thread-1] ProxyServer:76 - arguments.length = 0 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,238 INFO [pool-83-thread-1] OverviewWorkflow:117 - entering getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,238 DEBUG [pool-83-thread-1] OverviewWorkflow:118 - getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,238 INFO [pool-83-thread-1] OverviewWorkflow:130 - leaving getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:03,238 INFO [pool-83-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:14,410 DEBUG [Thread-4083] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:14,410 DEBUG [Thread-4083] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/LINISH - 22760265 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:14,410 DEBUG [Thread-4083] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::0::null::192::Mon Jan 12 11:52:14 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:16,910 DEBUG [Thread-4084] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:16,910 DEBUG [Thread-4084] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/LINISH - 22760265 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:16,910 DEBUG [Thread-4084] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::1::null::192::Mon Jan 12 11:52:16 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:16,910 DEBUG [pool-2-thread-154] DHRDevice:121 - DHR Trigger received for DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:16,910 DEBUG [pool-2-thread-154] DHRDevice:125 - Reading DHR for DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:16,910 DEBUG [pool-2-thread-154] OPCDataProviderDyn:354 - Read DHR data for: DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:18,441 DEBUG [pool-2-thread-154] DHRDevice:127 - Finished reading DHR for DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:34,410 DEBUG [Thread-4085] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:34,410 DEBUG [Thread-4085] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR3@RNA://$Global/TBCAT/FPI - 30957189 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:34,410 DEBUG [Thread-4085] OPCDataProviderDyn:295 - ::DB2011.DBW4004:INT::0::null::192::Mon Jan 12 11:52:34 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,160 DEBUG [Thread-4086] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,160 DEBUG [Thread-4086] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR3@RNA://$Global/TBCAT/FPI - 30957189 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,160 DEBUG [Thread-4086] OPCDataProviderDyn:295 - ::DB2011.DBW4004:INT::1::null::192::Mon Jan 12 11:52:37 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,160 DEBUG [pool-2-thread-155] DHRDevice:121 - DHR Trigger received for DHR3@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,160 DEBUG [pool-2-thread-155] DHRDevice:125 - Reading DHR for DHR3@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,160 DEBUG [pool-2-thread-155] OPCDataProviderDyn:354 - Read DHR data for: DHR3@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,410 DEBUG [Thread-4087] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,410 DEBUG [Thread-4087] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR1@RNA://$Global/TBCAT/CMM - 29135783 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,410 DEBUG [Thread-4087] OPCDataProviderDyn:295 - ::DB2011.DBW2044:INT::1::null::192::Mon Jan 12 11:52:37 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,410 DEBUG [pool-2-thread-156] DHRDevice:121 - DHR Trigger received for DHR1@RNA://$Global/TBCAT/CMM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,410 DEBUG [pool-2-thread-156] DHRDevice:125 - Reading DHR for DHR1@RNA://$Global/TBCAT/CMM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,410 DEBUG [pool-2-thread-156] OPCDataProviderDyn:354 - Read DHR data for: DHR1@RNA://$Global/TBCAT/CMM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,722 DEBUG [pool-12-thread-2] ProxyServer:73 - RemoteInvokationProcessor: Method is: deleteObserver INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,722 DEBUG [pool-12-thread-2] ProxyServer:74 - arguments: [Ljava.lang.Object;@c3f7d8 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,738 DEBUG [pool-12-thread-2] ProxyServer:76 - arguments.length = 1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,738 DEBUG [pool-12-thread-2] ProxyServer:82 - argument is null INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,738 INFO [pool-12-thread-2] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,785 INFO [pool-5-thread-43] CommandListenerActivity:63 - Processing message from command queue. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,785 INFO [pool-5-thread-43] CommandListenerActivity:72 - Processing request of type NewProxyServerRequest INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,801 INFO [pool-5-thread-43] ProxyServer:152 - Proxy server for DeclareScrapWorkflow up and running. Sending response. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,816 DEBUG [pool-84-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: toString INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,816 DEBUG [pool-84-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@17fb4c5 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,816 DEBUG [pool-84-thread-1] ProxyServer:76 - arguments.length = 0 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,816 INFO [pool-84-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,832 DEBUG [pool-84-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: addObserver INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,847 DEBUG [pool-84-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@1b140da INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,847 DEBUG [pool-84-thread-1] ProxyServer:76 - arguments.length = 1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,847 DEBUG [pool-84-thread-1] ProxyServer:82 - argument is null INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:37,847 INFO [pool-84-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:38,613 DEBUG [pool-2-thread-155] DHRDevice:127 - Finished reading DHR for DHR3@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:38,863 DEBUG [pool-2-thread-156] DHRDevice:127 - Finished reading DHR for DHR1@RNA://$Global/TBCAT/CMM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:38,910 DEBUG [Thread-4088] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:38,910 DEBUG [Thread-4088] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/FPI - 24112869 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:38,910 DEBUG [Thread-4088] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::0::null::192::Mon Jan 12 11:52:38 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:40,660 DEBUG [Thread-4089] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:40,660 DEBUG [Thread-4089] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/FPI - 24112869 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:40,660 DEBUG [Thread-4089] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::1::null::192::Mon Jan 12 11:52:40 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:40,660 DEBUG [pool-2-thread-157] DHRDevice:121 - DHR Trigger received for DHR2@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:40,660 DEBUG [pool-2-thread-157] DHRDevice:125 - Reading DHR for DHR2@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:40,660 DEBUG [pool-2-thread-157] OPCDataProviderDyn:354 - Read DHR data for: DHR2@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | 11:52:42,222 DEBUG [pool-2-thread-157] DHRDevice:127 - Finished reading DHR for DHR2@RNA://$Global/TBCAT/FPI INFO | jvm 1 | 2015/01/12 11:57:24 | com.datasweep.plantops.common.exceptions.DatasweepServerException: SQL Exception message: ORA-03111: break received on communication channel INFO | jvm 1 | 2015/01/12 11:57:24 | INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.coreserver.utility.ExceptionHandler.handleTransactionException(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.coreserver.sessionbeans.ClientUtility.ClientUtilityBean.getStoredProcArrayDataFromActive(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at sun.reflect.GeneratedMethodAccessor427.invoke(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.lang.reflect.Method.invoke(Method.java:597) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.invocation.Invocation.performCall(Invocation.java:386) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:233) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:378) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:282) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.Container.invoke(Container.java:1092) INFO | jvm 1 | 2015/01/12 11:57:24 | at sun.reflect.GeneratedMethodAccessor425.invoke(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.lang.reflect.Method.invoke(Method.java:597) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.invocation.unified.server.UnifiedInvokerHA.invoke(UnifiedInvokerHA.java:149) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:768) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:721) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:575) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:213) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.Client.invoke(Client.java:1917) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.Client.invoke(Client.java:768) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.invocation.unified.interfaces.UnifiedInvokerHAProxy.invoke(UnifiedInvokerHAProxy.java:211) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.TransactionStickyInterceptor.invoke(TransactionStickyInterceptor.java:40) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.ejb.RetryInterceptor.invoke(RetryInterceptor.java:177) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.ejb.SecurityContextInterceptor.invoke(SecurityContextInterceptor.java:64) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101) INFO | jvm 1 | 2015/01/12 11:57:24 | at $Proxy19.getStoredProcArrayDataFromActive(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.jboss.rmiImpl.ClientUtilityRMIImpl$PrivilegedAction_5.run(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.security.AccessController.doPrivileged(Native Method) INFO | jvm 1 | 2015/01/12 11:57:24 | at javax.security.auth.Subject.doAs(Subject.java:337) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.jboss.RmiExecuteRetry.doRetryAction(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.jboss.RmiExecuteRetry.run(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.jboss.ProxyFactoryJBossImpl._run(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.ProxyFactory.dispatch(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.ProxyFactory$1.run(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.jboss.rmiImpl.ClientUtilityRMIImpl.getStoredProcArrayDataFromActive(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.compatibility.manager.UtilityManager.getStoredProcArrayDataFromActive(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.compatibility.pnutsfunctions.utility.getStoredProcArrayDataFromActive.exec(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at pnuts.lang.PnutsFunction.call(PnutsFunction.java:157) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.compatibility.pnuts.FunctionsImpl.getStoredProcArrayDataFromActive(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.database.StoredProcedure.execute(StoredProcedure.java:72) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.database.StoredProcDataProvider.writeList(StoredProcDataProvider.java:102) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.DataProvider.write(DataProvider.java:207) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.DataProvider.write(DataProvider.java:199) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.database.DBAlertDataProvider$1.runOnce(DBAlertDataProvider.java:96) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.DataProvider$AbstractDataTask.run(DataProvider.java:47) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.util.concurrent.FutureTask.run(FutureTask.java:138) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.lang.Thread.run(Thread.java:619) INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,613 DEBUG [pool-84-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: deleteObserver INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,613 DEBUG [pool-84-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@cb7ae6 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,613 DEBUG [pool-84-thread-1] ProxyServer:76 - arguments.length = 1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,613 DEBUG [pool-84-thread-1] ProxyServer:82 - argument is null INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,613 INFO [pool-84-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,910 INFO [pool-5-thread-43] CommandListenerActivity:63 - Processing message from command queue. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,910 INFO [pool-5-thread-43] CommandListenerActivity:72 - Processing request of type NewProxyServerRequest INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,926 INFO [pool-5-thread-43] ProxyServer:152 - Proxy server for OverviewWorkflow up and running. Sending response. INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,941 DEBUG [pool-85-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: toString INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,941 DEBUG [pool-85-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@5c1410 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,941 DEBUG [pool-85-thread-1] ProxyServer:76 - arguments.length = 0 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,957 INFO [pool-85-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,957 DEBUG [pool-85-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: addObserver INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,957 DEBUG [pool-85-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@51fc91 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,957 DEBUG [pool-85-thread-1] ProxyServer:76 - arguments.length = 1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,957 DEBUG [pool-85-thread-1] ProxyServer:82 - argument is null INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,957 INFO [pool-85-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,972 DEBUG [pool-85-thread-1] ProxyServer:73 - RemoteInvokationProcessor: Method is: getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,972 DEBUG [pool-85-thread-1] ProxyServer:74 - arguments: [Ljava.lang.Object;@1f8bd65 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,972 DEBUG [pool-85-thread-1] ProxyServer:76 - arguments.length = 0 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,972 INFO [pool-85-thread-1] OverviewWorkflow:117 - entering getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,972 DEBUG [pool-85-thread-1] OverviewWorkflow:118 - getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,972 INFO [pool-85-thread-1] OverviewWorkflow:130 - leaving getOverview INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:04,972 INFO [pool-85-thread-1] ProxyServer:103 - invocation succesfull INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:06,410 DEBUG [Thread-4091] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:06,410 DEBUG [Thread-4091] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR1@RNA://$Global/TBCAT/GRIDBLAST - 6767312 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:06,410 DEBUG [Thread-4091] OPCDataProviderDyn:295 - ::DB2011.DBW2044:INT::0::null::192::Mon Jan 12 11:53:06 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:07,410 DEBUG [Thread-4092] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:07,410 DEBUG [Thread-4092] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR1@RNA://$Global/TBCAT/GRIDBLAST - 6767312 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:07,410 DEBUG [Thread-4092] OPCDataProviderDyn:295 - ::DB2011.DBW2044:INT::1::null::192::Mon Jan 12 11:53:07 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:07,410 DEBUG [pool-2-thread-158] DHRDevice:121 - DHR Trigger received for DHR1@RNA://$Global/TBCAT/GRIDBLAST INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:07,410 DEBUG [pool-2-thread-158] DHRDevice:125 - Reading DHR for DHR1@RNA://$Global/TBCAT/GRIDBLAST INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:07,410 DEBUG [pool-2-thread-158] OPCDataProviderDyn:354 - Read DHR data for: DHR1@RNA://$Global/TBCAT/GRIDBLAST INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:08,613 DEBUG [pool-2-thread-158] DHRDevice:127 - Finished reading DHR for DHR1@RNA://$Global/TBCAT/GRIDBLAST INFO | jvm 1 | 2015/01/12 11:57:24 | com.datasweep.plantops.common.exceptions.DatasweepServerException: SQL Exception message: ORA-03111: break received on communication channel INFO | jvm 1 | 2015/01/12 11:57:24 | INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.coreserver.utility.ExceptionHandler.handleTransactionException(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.coreserver.sessionbeans.ClientUtility.ClientUtilityBean.getStoredProcArrayDataFromActive(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at sun.reflect.GeneratedMethodAccessor427.invoke(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.lang.reflect.Method.invoke(Method.java:597) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.invocation.Invocation.performCall(Invocation.java:386) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:233) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:378) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:282) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.ejb.Container.invoke(Container.java:1092) INFO | jvm 1 | 2015/01/12 11:57:24 | at sun.reflect.GeneratedMethodAccessor425.invoke(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.lang.reflect.Method.invoke(Method.java:597) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.invocation.unified.server.UnifiedInvokerHA.invoke(UnifiedInvokerHA.java:149) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:768) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:721) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:575) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:213) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.Client.invoke(Client.java:1917) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.remoting.Client.invoke(Client.java:768) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.invocation.unified.interfaces.UnifiedInvokerHAProxy.invoke(UnifiedInvokerHAProxy.java:211) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.TransactionStickyInterceptor.invoke(TransactionStickyInterceptor.java:40) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.ejb.RetryInterceptor.invoke(RetryInterceptor.java:177) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.ejb.SecurityContextInterceptor.invoke(SecurityContextInterceptor.java:64) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) INFO | jvm 1 | 2015/01/12 11:57:24 | at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101) INFO | jvm 1 | 2015/01/12 11:57:24 | at $Proxy19.getStoredProcArrayDataFromActive(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.jboss.rmiImpl.ClientUtilityRMIImpl$PrivilegedAction_5.run(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.security.AccessController.doPrivileged(Native Method) INFO | jvm 1 | 2015/01/12 11:57:24 | at javax.security.auth.Subject.doAs(Subject.java:337) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.jboss.RmiExecuteRetry.doRetryAction(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.jboss.RmiExecuteRetry.run(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.jboss.ProxyFactoryJBossImpl._run(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.ProxyFactory.dispatch(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.ProxyFactory$1.run(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.plantops.proxies.jboss.rmiImpl.ClientUtilityRMIImpl.getStoredProcArrayDataFromActive(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.compatibility.manager.UtilityManager.getStoredProcArrayDataFromActive(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.compatibility.pnutsfunctions.utility.getStoredProcArrayDataFromActive.exec(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at pnuts.lang.PnutsFunction.call(PnutsFunction.java:157) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.datasweep.compatibility.pnuts.FunctionsImpl.getStoredProcArrayDataFromActive(Unknown Source) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.database.StoredProcedure.execute(StoredProcedure.java:72) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.database.StoredProcDataProvider.writeList(StoredProcDataProvider.java:102) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.DataProvider.write(DataProvider.java:207) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.DataProvider.write(DataProvider.java:199) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.database.DBAlertDataProvider$1.runOnce(DBAlertDataProvider.java:96) INFO | jvm 1 | 2015/01/12 11:57:24 | at com.systec.data.impl.DataProvider$AbstractDataTask.run(DataProvider.java:47) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.util.concurrent.FutureTask.run(FutureTask.java:138) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) INFO | jvm 1 | 2015/01/12 11:57:24 | at java.lang.Thread.run(Thread.java:619) INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:11,410 DEBUG [Thread-4093] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:11,410 DEBUG [Thread-4093] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR1@RNA://$Global/TBCAT/GRINDMILL2 - 30046273 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:11,410 DEBUG [Thread-4093] OPCDataProviderDyn:295 - ::DB2011.DBW2044:INT::1::null::192::Mon Jan 12 11:53:11 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:11,410 DEBUG [pool-2-thread-159] DHRDevice:121 - DHR Trigger received for DHR1@RNA://$Global/TBCAT/GRINDMILL2 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:11,410 DEBUG [pool-2-thread-159] DHRDevice:125 - Reading DHR for DHR1@RNA://$Global/TBCAT/GRINDMILL2 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:11,410 DEBUG [pool-2-thread-159] OPCDataProviderDyn:354 - Read DHR data for: DHR1@RNA://$Global/TBCAT/GRINDMILL2 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:12,941 DEBUG [pool-2-thread-159] DHRDevice:127 - Finished reading DHR for DHR1@RNA://$Global/TBCAT/GRINDMILL2 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:15,910 DEBUG [Thread-4094] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:15,910 DEBUG [Thread-4094] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/FORM - 15915821 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:15,910 DEBUG [Thread-4094] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::0::null::192::Mon Jan 12 11:53:15 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:17,160 DEBUG [Thread-4095] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:17,160 DEBUG [Thread-4095] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/LINISH - 22760265 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:17,160 DEBUG [Thread-4095] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::0::null::192::Mon Jan 12 11:53:16 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:18,660 DEBUG [Thread-4096] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:18,660 DEBUG [Thread-4096] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/LINISH - 22760265 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:18,660 DEBUG [Thread-4096] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::1::null::192::Mon Jan 12 11:53:18 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:18,660 DEBUG [pool-2-thread-160] DHRDevice:121 - DHR Trigger received for DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:18,660 DEBUG [pool-2-thread-160] DHRDevice:125 - Reading DHR for DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:18,660 DEBUG [pool-2-thread-160] OPCDataProviderDyn:354 - Read DHR data for: DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:19,910 DEBUG [Thread-4097] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:19,910 DEBUG [Thread-4097] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/FORM - 15915821 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:19,910 DEBUG [Thread-4097] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::1::null::192::Mon Jan 12 11:53:19 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:19,910 DEBUG [pool-2-thread-161] DHRDevice:121 - DHR Trigger received for DHR2@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:19,910 DEBUG [pool-2-thread-161] DHRDevice:125 - Reading DHR for DHR2@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:19,910 DEBUG [pool-2-thread-161] OPCDataProviderDyn:354 - Read DHR data for: DHR2@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:20,035 DEBUG [pool-2-thread-160] DHRDevice:127 - Finished reading DHR for DHR2@RNA://$Global/TBCAT/LINISH INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:21,551 DEBUG [pool-2-thread-161] DHRDevice:127 - Finished reading DHR for DHR2@RNA://$Global/TBCAT/FORM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:37,160 DEBUG [Thread-4098] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:37,160 DEBUG [Thread-4098] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR1@RNA://$Global/TBCAT/CMM - 29135783 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:37,160 DEBUG [Thread-4098] OPCDataProviderDyn:295 - ::DB2011.DBW2044:INT::0::null::192::Mon Jan 12 11:53:36 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:38,160 DEBUG [Thread-4099] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:38,160 DEBUG [Thread-4099] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR1@RNA://$Global/TBCAT/CMM - 29135783 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:38,160 DEBUG [Thread-4099] OPCDataProviderDyn:295 - ::DB2011.DBW2044:INT::1::null::192::Mon Jan 12 11:53:38 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:38,160 DEBUG [pool-2-thread-162] DHRDevice:121 - DHR Trigger received for DHR1@RNA://$Global/TBCAT/CMM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:38,160 DEBUG [pool-2-thread-162] DHRDevice:125 - Reading DHR for DHR1@RNA://$Global/TBCAT/CMM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:38,160 DEBUG [pool-2-thread-162] OPCDataProviderDyn:354 - Read DHR data for: DHR1@RNA://$Global/TBCAT/CMM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:39,754 DEBUG [pool-2-thread-162] DHRDevice:127 - Finished reading DHR for DHR1@RNA://$Global/TBCAT/CMM INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:48,660 DEBUG [Thread-4100] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:48,660 DEBUG [Thread-4100] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR1@RNA://$Global/TBCAT/GRINDMILL1 - 17286677 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:48,660 DEBUG [Thread-4100] OPCDataProviderDyn:295 - ::DB2011.DBW2044:INT::1::null::192::Mon Jan 12 11:53:48 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:48,660 DEBUG [pool-2-thread-163] DHRDevice:121 - DHR Trigger received for DHR1@RNA://$Global/TBCAT/GRINDMILL1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:48,660 DEBUG [pool-2-thread-163] DHRDevice:125 - Reading DHR for DHR1@RNA://$Global/TBCAT/GRINDMILL1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:48,660 DEBUG [pool-2-thread-163] OPCDataProviderDyn:354 - Read DHR data for: DHR1@RNA://$Global/TBCAT/GRINDMILL1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:50,566 DEBUG [pool-2-thread-163] DHRDevice:127 - Finished reading DHR for DHR1@RNA://$Global/TBCAT/GRINDMILL1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:50,660 DEBUG [Thread-4101] OPCDataProviderDyn:282 - dataChange event in com.systec.data.dao.ALDhrTriggerDTO INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:50,660 DEBUG [Thread-4101] OPCDataProviderDyn:286 - DataChange: DHR data for: DHR2@RNA://$Global/TBCAT/GRINDMILL1 - 7406511 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:50,660 DEBUG [Thread-4101] OPCDataProviderDyn:295 - ::DB2011.DBW3024:INT::1::null::192::Mon Jan 12 11:53:50 GMT 2015 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:50,660 DEBUG [pool-2-thread-164] DHRDevice:121 - DHR Trigger received for DHR2@RNA://$Global/TBCAT/GRINDMILL1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:50,660 DEBUG [pool-2-thread-164] DHRDevice:125 - Reading DHR for DHR2@RNA://$Global/TBCAT/GRINDMILL1 INFO | jvm 1 | 2015/01/12 11:57:24 | 11:53:50,660 DEBUG [pool-2-thread-164] OPCDataProviderDyn:354 - Read DHR data for: DHR2@RNA://$Global/TBCAT/GRINDMILL1 INFO |... [truncated message content] |
|
From: Mark K. T. <mk...@cd...> - 2015-01-22 15:12:52
|
Hi all We are running java programs (engines) installed as Windows services. They are using the 32-bit wrapper, but are running on Windows 64-bit servers with Java 64-bit jvms. There are some warnings during startup that wrapper-windows-x86-64.dll is not found, but the wrapper and program runs anyway. Question is, will buying licenses for 64-bit version of the wrapper yield any performance increase? I hope I made myself understandable. Best regards Mark Kvistgaard Thomsen Application Consultant [cid:image001.jpg@01D0365B.746F27F0] |
|
From: Simon K. <si...@kr...> - 2015-01-20 15:05:30
|
Hi Jeff, As you might have noted, the source for the Community Edition is readily available. However, there is no compiled version for the Java Service Wrapper available from Tanuki. This is why I compile these wrappers for 64-bit Windows myself and make them available on my website: https://www.krenger.ch/projects/ So if you are looking for a compiled version of the wrapper for Windows x64, you can find that there. Please note that new releases are often available a few weeks after their release and not earlier, although I try to provide new versions as soon as possible. All the best, Simon On 11 January 2015 at 15:06, Jeff Nelson <je...@ci...> wrote: > Hi, > > The Concourse <http://concoursedb.com/> project is an open source > database that uses the community edition of the wrapper. We'd like to add > support for Windows, but that depends on being able to use the 64-bit > Windows version of the wrapper. Is there a timeline for when this will be > made available under the Community Licensing Agreement? If it is not on the > horizon, are there suggested workarounds? > > Thanks, > Jeff > > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Jeff N. <je...@ci...> - 2015-01-11 14:07:09
|
Hi, The Concourse <http://concoursedb.com/> project is an open source database that uses the community edition of the wrapper. We'd like to add support for Windows, but that depends on being able to use the 64-bit Windows version of the wrapper. Is there a timeline for when this will be made available under the Community Licensing Agreement? If it is not on the horizon, are there suggested workarounds? Thanks, Jeff |
|
From: Alexandre K. <ale...@ta...> - 2015-01-07 04:11:41
|
Mark, Thank you for your interest in the Wrapper. Currently there is no support, but from version 3.6.0 you will be able to use log4j with the Wrapper. For example, now all the messages from your Java application are logged with level INFO in the Wrapper log file: INFO | jvm 1 | | error message from my java application >From version 3.6.0, the messages from your application will be logged with the correct log level: ERROR | jvm 1 | myapp.com.logger | error message from my java application Unfortunately we don't have a release date yet. Regards, Alexandre Klein Alexandre Klein Tanuki Software, Ltd. 6-16-7-1001 Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel: +81-3-3878-3211 Fax: +81-3-3878-0313 http://www.tanukisoftware.com On Tue, Jan 6, 2015 at 5:30 AM, Mark Sumner <mar...@mc...> wrote: > Hi, > I'm quite new to using wrapper and have a simple query on logging. Is > there any support for using log4j for the wrapper log file (as opposed > to the java process it is spawning) ? If not, is there any plan to add > this functionality? > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Mark S. <mar...@mc...> - 2015-01-05 20:55:44
|
Hi, I'm quite new to using wrapper and have a simple query on logging. Is there any support for using log4j for the wrapper log file (as opposed to the java process it is spawning) ? If not, is there any plan to add this functionality? |
|
From: lluis <ll...@in...> - 2014-12-31 11:36:36
|
Hi, checked without wrapper and it still ignores https.protocols so it seems not related to wrapper maybe adito modifies these settings on runtime thanks for your help Dannes! Lluís El dc 31 de 12 de 2014 a les 11:31 +0100, en/na Dannes Wessels va escriure: > Hi, > > > > On 31 Dec 2014, at 9:35 , lluis <ll...@in...> wrote: > > > > some more hints? > > > sorry, though your way of checking might not be ok, I would not > know….. what you should check is what happens if you don;t use the > wrapper to start the same application with the same parameters. Also > could verify with jconsole if the commandline parameters are actually > send into the JVM. > > > anyway I don’t think this mailinglist is the correct place to ask a > JVM specific question. It is better to > scan http://stackoverflow.com for the same question, or post it there > if it is not being asked before. > > > cheers > > > Dannes > > -- Lluís Gili Ingent Grup Systems ~ http://www.ingent.net ~ Tel. 933935931 |
|
From: Dannes W. <da...@ex...> - 2014-12-31 10:32:59
|
please check wrapper.java.additional.1=-Dhttps.protocols=TLSv1 as well (without the double quotes around the value) cheers Dannes > On 31 Dec 2014, at 11:31 , Dannes Wessels <da...@ex...> wrote: > >> On 31 Dec 2014, at 9:35 , lluis <ll...@in...> wrote: >> >> some more hints? > > sorry, though your way of checking might not be ok, I would not know….. what you should check is what happens if you don;t use the wrapper to start the same application with the same parameters. Also could verify with jconsole if the commandline parameters are actually send into the JVM. > > anyway I don’t think this mailinglist is the correct place to ask a JVM specific question. It is better to scan http://stackoverflow.com for the same question, or post it there if it is not being asked before. |
|
From: Dannes W. <da...@ex...> - 2014-12-31 10:31:32
|
Hi, > On 31 Dec 2014, at 9:35 , lluis <ll...@in...> wrote: > > some more hints? sorry, though your way of checking might not be ok, I would not know….. what you should check is what happens if you don;t use the wrapper to start the same application with the same parameters. Also could verify with jconsole if the commandline parameters are actually send into the JVM. anyway I don’t think this mailinglist is the correct place to ask a JVM specific question. It is better to scan http://stackoverflow.com <http://stackoverflow.com/> for the same question, or post it there if it is not being asked before. cheers Dannes |
|
From: lluis <ll...@in...> - 2014-12-31 08:35:32
|
Hello, I've tried installing Oracle JDK 7, with same results # java -version java version "1.7.0_71" Java(TM) SE Runtime Environment (build 1.7.0_71-b14) Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) now the wrapper command looks like this: /usr/java/jdk1.7.0_71/bin/java -Dhttps.protocols="TLSv1" -Dsun.security.ssl.allowUnsafeRenegotiation=false (...) (I've also added allowUnsafeRenegotiation=false) some more hints? thanks, Lluís El dt 30 de 12 de 2014 a les 20:01 +0100, en/na Dannes Wessels va escriure: > Hi, > > > On 30 Dec 2014, at 14:57 , lluis <ll...@in...> wrote: > > > > I am trying to disable SSLv3 to prevent POODLE attack on adito, which > > uses wrapper. I've tried to add this > > to /usr/local/src/adito-0.9.1/conf/wrapper.conf: > > > > wrapper.java.additional.1=-Dhttps.protocols="TLSv1" > > > > and in fact is added to the java command: > > > > /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java > > the instructions you use are for the OracleVM ; I have my doubts whether it can be used for the OpenJDK6 VM (very old and incompatible with too much code). > > The work around is... install the OracleVM ? > > regards > > Dannes > -- Lluís Gili Ingent Grup Systems ~ http://www.ingent.net ~ Tel. 933935931 |
|
From: Dannes W. <da...@ex...> - 2014-12-30 19:01:58
|
Hi, > On 30 Dec 2014, at 14:57 , lluis <ll...@in...> wrote: > > I am trying to disable SSLv3 to prevent POODLE attack on adito, which > uses wrapper. I've tried to add this > to /usr/local/src/adito-0.9.1/conf/wrapper.conf: > > wrapper.java.additional.1=-Dhttps.protocols="TLSv1" > > and in fact is added to the java command: > > /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java the instructions you use are for the OracleVM ; I have my doubts whether it can be used for the OpenJDK6 VM (very old and incompatible with too much code). The work around is... install the OracleVM ? regards Dannes |
|
From: lluis <ll...@in...> - 2014-12-30 14:23:06
|
Hello, I am trying to disable SSLv3 to prevent POODLE attack on adito, which uses wrapper. I've tried to add this to /usr/local/src/adito-0.9.1/conf/wrapper.conf: wrapper.java.additional.1=-Dhttps.protocols="TLSv1" and in fact is added to the java command: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java -Dhttps.protocols="TLSv1" -Xms64m -Xmx512m -Djava.library.path=install/platforms/linux/x86 -classpath build/boot:lib/adito-boot.jar -Dwrapper.key=iegai2ohDeiThaeK -Dwrapper.port=32000 -Dwrapper.use_system_time=TRUE -Dwrapper.version=3.1.2 -Dwrapper.native_library=wrapper -Dwrapper.service=TRUE -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=1 com.adito.boot.Bootstrap but it is still responding to SSLv3 requests: # openssl s_client -connect localhost:443 -ssl3 CONNECTED(00000003) (...) verify error:num=18:self signed certificate * some system info: CentOS 5.8 (2.6.18-308.8.2.el5) openssl-0.9.8e-31.el5_11 adito-0.9.1 Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Wrapper (Version 3.2.3) any hints to disable SSLv3? -- Lluís Gili Ingent Grup Systems ~ http://www.ingent.net ~ Tel. 933935931 |
|
From: Tim L. <tim...@gm...> - 2014-12-23 16:04:57
|
Sorry for the confusion, but this is about a memory leak in glibc. Not in the wrapper itself. The wrapper uses certain glibc system calls which harbor the memory leak. That's why you need to either upgrade glibc or still apply a patch to the wrapper in case you are using CentOS or another Linux system using that specific version of glibc. AFAIK the fix for glibc was backported to older versions so those systems could be safely updated. Regards, Tim On Tue, Dec 23, 2014 at 4:58 PM, Casey Jordan <cas...@jo...> wrote: > Hi Tim, > > I was under the impression that fix was in 3.5.26? It seems to indicate > this in the release notes, Is this not the case? > > On Tue, Dec 23, 2014 at 10:55 AM, Tim Lammens <tim...@gm...> > wrote: > >> On CentOS there is still a memory leak in the glibc code, you can avoid >> this by applying one of the patches I provided on the wrapper code if you >> want to avoid updating glibc. It has to do with the append system calls. >> >> Regards, >> Tim >> >> >> On 23-dec.-2014, at 16:45, Casey Jordan <cas...@jo...> wrote: >> >> So I wanted to give an update on this. I created a simple stress testing >> script that triggered lots of logging to occur. I tested this on the 3.5.17 >> version and was easily able to see the memory leak as the wrapper process >> rose to about 3.5% (250MB) of memory usage over running this script for >> about 2 hours. >> >> However, now I am running this same script on 2.5.26, it's been running >> for about 30 min now and is already up to 1% system memory usage. I am >> going to keep running for a few hours and see what results I get. However, >> I am concerned because on non CentOs systems we never see the wrapper >> process even reach .1% consumption even after running for 6 months. >> >> Perhaps what I am seeing is just some artifact of something else >> (cache/buffers?)? Maybe there is a better way to test this before I put it >> back into production? (I don't really want to get into doing a valgrind >> session :) >> >> Thanks >> >> On Sun, Dec 21, 2014 at 10:27 PM, Casey Jordan <cas...@jo...> >> wrote: >> >>> Leif, >>> >>> Thanks for replying so quickly! That's great to hear, I'm excited to try >>> out the new version. >>> >>> >>> On Sunday, December 21, 2014, Leif Mortenson < >>> lei...@ta...> wrote: >>> >>>> Casey, >>>> Rather than patching the Wrapper, I would suggest the released version >>>> with the fix. There have been a number of other important improvements as >>>> well. >>>> We usually wait a couple weeks after a release before deciding to raise >>>> a version to stable. This is done to make sure that there are no >>>> unexpected errors reported from the user base. >>>> So far 3.5.26 has been quite stable. >>>> >>>> Cheers, >>>> Leif >>>> >>>> >>>> On Sun, Dec 21, 2014 at 9:52 AM, Casey Jordan <cas...@jo...> >>>> wrote: >>>>> >>>>> Hi Tim & Community, >>>>> >>>>> Sorry I had to go back and review your previous comments before I >>>>> realized you had posted those patches and also provided me with >>>>> instructions. >>>>> >>>>> I am currently running wrapper version 3.5.17. I also saw that 3.5.26 >>>>> appears to have the memory leak fixes in it (Based on reading the release >>>>> notes). >>>>> >>>>> Which of the following would be the best option? >>>>> >>>>> Patch v3.5.17 >>>>> Upgrade to v3.5.25 and patch >>>>> Use v3.5.26 (Which I believe contains the fix I need) >>>>> >>>>> Obviously using 3.5.26 seems the simplest approach here, but I just >>>>> wanted to double check with the community. >>>>> >>>>> Thanks, your help is much appreciated. >>>>> >>>>> On Sat, Dec 20, 2014 at 6:46 PM, Casey Jordan <cas...@jo... >>>>> > wrote: >>>>> >>>>>> Ok, so I have been monitoring for a bit now and I can definitely say >>>>>> that I have this memory leak and it is causing the issues I am experiencing. >>>>>> >>>>>> Now the issue remains that I do not believe that I can upgrade glibc >>>>>> on my system, given that all the threads I read say that will cause major >>>>>> problems. Also, I need to use CentOS 7 if at all possible. >>>>>> >>>>>> I noticed in the previously referenced thread that someone created a >>>>>> patch directly in the wrapper to also fix this issue, does anyone know if >>>>>> this fix made it into a release that I could use? >>>>>> >>>>>> Thanks! >>>>>> >>>>> >>>>> >>> >>> -- >>> -- >>> Casey Jordan >>> easyDITA a product of Jorsek LLC >>> "CaseyDJordan" on LinkedIn, Twitter & Facebook >>> (585) 348 7399 >>> easydita.com >>> >>> >>> This message is intended only for the use of the Addressee(s) and may >>> contain information that is privileged, confidential, and/or exempt from >>> disclosure under applicable law. If you are not the intended recipient, >>> please be advised that any disclosure copying, distribution, or use of >>> the information contained herein is prohibited. If you have received >>> this communication in error, please destroy all copies of the message, >>> whether in electronic or hard copy format, as well as attachments, and >>> immediately contact the sender by replying to this e-mail or by phone. >>> Thank you. >>> >>> >> >> >> -- >> -- >> Casey Jordan >> easyDITA a product of Jorsek LLC >> "CaseyDJordan" on LinkedIn, Twitter & Facebook >> (585) 348 7399 >> easydita.com >> >> >> This message is intended only for the use of the Addressee(s) and may >> contain information that is privileged, confidential, and/or exempt from >> disclosure under applicable law. If you are not the intended recipient, >> please be advised that any disclosure copying, distribution, or use of >> the information contained herein is prohibited. If you have received >> this communication in error, please destroy all copies of the message, >> whether in electronic or hard copy format, as well as attachments, and >> immediately contact the sender by replying to this e-mail or by phone. >> Thank you. >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming! The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net >> >> _______________________________________________ >> Wrapper-user mailing list >> Wra...@li... >> https://lists.sourceforge.net/lists/listinfo/wrapper-user >> >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming! The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net >> _______________________________________________ >> Wrapper-user mailing list >> Wra...@li... >> https://lists.sourceforge.net/lists/listinfo/wrapper-user >> >> > > > -- > -- > Casey Jordan > easyDITA a product of Jorsek LLC > "CaseyDJordan" on LinkedIn, Twitter & Facebook > (585) 348 7399 > easydita.com > > > This message is intended only for the use of the Addressee(s) and may > contain information that is privileged, confidential, and/or exempt from > disclosure under applicable law. If you are not the intended recipient, > please be advised that any disclosure copying, distribution, or use of > the information contained herein is prohibited. If you have received > this communication in error, please destroy all copies of the message, > whether in electronic or hard copy format, as well as attachments, and > immediately contact the sender by replying to this e-mail or by phone. > Thank you. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Casey J. <cas...@jo...> - 2014-12-23 15:58:25
|
Hi Tim, I was under the impression that fix was in 3.5.26? It seems to indicate this in the release notes, Is this not the case? On Tue, Dec 23, 2014 at 10:55 AM, Tim Lammens <tim...@gm...> wrote: > On CentOS there is still a memory leak in the glibc code, you can avoid > this by applying one of the patches I provided on the wrapper code if you > want to avoid updating glibc. It has to do with the append system calls. > > Regards, > Tim > > > On 23-dec.-2014, at 16:45, Casey Jordan <cas...@jo...> wrote: > > So I wanted to give an update on this. I created a simple stress testing > script that triggered lots of logging to occur. I tested this on the 3.5.17 > version and was easily able to see the memory leak as the wrapper process > rose to about 3.5% (250MB) of memory usage over running this script for > about 2 hours. > > However, now I am running this same script on 2.5.26, it's been running > for about 30 min now and is already up to 1% system memory usage. I am > going to keep running for a few hours and see what results I get. However, > I am concerned because on non CentOs systems we never see the wrapper > process even reach .1% consumption even after running for 6 months. > > Perhaps what I am seeing is just some artifact of something else > (cache/buffers?)? Maybe there is a better way to test this before I put it > back into production? (I don't really want to get into doing a valgrind > session :) > > Thanks > > On Sun, Dec 21, 2014 at 10:27 PM, Casey Jordan <cas...@jo...> > wrote: > >> Leif, >> >> Thanks for replying so quickly! That's great to hear, I'm excited to try >> out the new version. >> >> >> On Sunday, December 21, 2014, Leif Mortenson < >> lei...@ta...> wrote: >> >>> Casey, >>> Rather than patching the Wrapper, I would suggest the released version >>> with the fix. There have been a number of other important improvements as >>> well. >>> We usually wait a couple weeks after a release before deciding to raise >>> a version to stable. This is done to make sure that there are no >>> unexpected errors reported from the user base. >>> So far 3.5.26 has been quite stable. >>> >>> Cheers, >>> Leif >>> >>> >>> On Sun, Dec 21, 2014 at 9:52 AM, Casey Jordan <cas...@jo...> >>> wrote: >>>> >>>> Hi Tim & Community, >>>> >>>> Sorry I had to go back and review your previous comments before I >>>> realized you had posted those patches and also provided me with >>>> instructions. >>>> >>>> I am currently running wrapper version 3.5.17. I also saw that 3.5.26 >>>> appears to have the memory leak fixes in it (Based on reading the release >>>> notes). >>>> >>>> Which of the following would be the best option? >>>> >>>> Patch v3.5.17 >>>> Upgrade to v3.5.25 and patch >>>> Use v3.5.26 (Which I believe contains the fix I need) >>>> >>>> Obviously using 3.5.26 seems the simplest approach here, but I just >>>> wanted to double check with the community. >>>> >>>> Thanks, your help is much appreciated. >>>> >>>> On Sat, Dec 20, 2014 at 6:46 PM, Casey Jordan <cas...@jo...> >>>> wrote: >>>> >>>>> Ok, so I have been monitoring for a bit now and I can definitely say >>>>> that I have this memory leak and it is causing the issues I am experiencing. >>>>> >>>>> Now the issue remains that I do not believe that I can upgrade glibc >>>>> on my system, given that all the threads I read say that will cause major >>>>> problems. Also, I need to use CentOS 7 if at all possible. >>>>> >>>>> I noticed in the previously referenced thread that someone created a >>>>> patch directly in the wrapper to also fix this issue, does anyone know if >>>>> this fix made it into a release that I could use? >>>>> >>>>> Thanks! >>>>> >>>> >>>> >> >> -- >> -- >> Casey Jordan >> easyDITA a product of Jorsek LLC >> "CaseyDJordan" on LinkedIn, Twitter & Facebook >> (585) 348 7399 >> easydita.com >> >> >> This message is intended only for the use of the Addressee(s) and may >> contain information that is privileged, confidential, and/or exempt from >> disclosure under applicable law. If you are not the intended recipient, >> please be advised that any disclosure copying, distribution, or use of >> the information contained herein is prohibited. If you have received >> this communication in error, please destroy all copies of the message, >> whether in electronic or hard copy format, as well as attachments, and >> immediately contact the sender by replying to this e-mail or by phone. >> Thank you. >> >> > > > -- > -- > Casey Jordan > easyDITA a product of Jorsek LLC > "CaseyDJordan" on LinkedIn, Twitter & Facebook > (585) 348 7399 > easydita.com > > > This message is intended only for the use of the Addressee(s) and may > contain information that is privileged, confidential, and/or exempt from > disclosure under applicable law. If you are not the intended recipient, > please be advised that any disclosure copying, distribution, or use of > the information contained herein is prohibited. If you have received > this communication in error, please destroy all copies of the message, > whether in electronic or hard copy format, as well as attachments, and > immediately contact the sender by replying to this e-mail or by phone. > Thank you. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > -- -- Casey Jordan easyDITA a product of Jorsek LLC "CaseyDJordan" on LinkedIn, Twitter & Facebook (585) 348 7399 easydita.com This message is intended only for the use of the Addressee(s) and may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, please be advised that any disclosure copying, distribution, or use of the information contained herein is prohibited. If you have received this communication in error, please destroy all copies of the message, whether in electronic or hard copy format, as well as attachments, and immediately contact the sender by replying to this e-mail or by phone. Thank you. |
|
From: Tim L. <tim...@gm...> - 2014-12-23 15:55:28
|
On CentOS there is still a memory leak in the glibc code, you can avoid this by applying one of the patches I provided on the wrapper code if you want to avoid updating glibc. It has to do with the append system calls. Regards, Tim > On 23-dec.-2014, at 16:45, Casey Jordan <cas...@jo...> wrote: > > So I wanted to give an update on this. I created a simple stress testing script that triggered lots of logging to occur. I tested this on the 3.5.17 version and was easily able to see the memory leak as the wrapper process rose to about 3.5% (250MB) of memory usage over running this script for about 2 hours. > > However, now I am running this same script on 2.5.26, it's been running for about 30 min now and is already up to 1% system memory usage. I am going to keep running for a few hours and see what results I get. However, I am concerned because on non CentOs systems we never see the wrapper process even reach .1% consumption even after running for 6 months. > > Perhaps what I am seeing is just some artifact of something else (cache/buffers?)? Maybe there is a better way to test this before I put it back into production? (I don't really want to get into doing a valgrind session :) > > Thanks > >> On Sun, Dec 21, 2014 at 10:27 PM, Casey Jordan <cas...@jo...> wrote: >> Leif, >> >> Thanks for replying so quickly! That's great to hear, I'm excited to try out the new version. >> >> >>> On Sunday, December 21, 2014, Leif Mortenson <lei...@ta...> wrote: >>> Casey, >>> Rather than patching the Wrapper, I would suggest the released version with the fix. There have been a number of other important improvements as well. >>> We usually wait a couple weeks after a release before deciding to raise a version to stable. This is done to make sure that there are no unexpected errors reported from the user base. >>> So far 3.5.26 has been quite stable. >>> >>> Cheers, >>> Leif >>> >>> >>>> On Sun, Dec 21, 2014 at 9:52 AM, Casey Jordan <cas...@jo...> wrote: >>>> Hi Tim & Community, >>>> >>>> Sorry I had to go back and review your previous comments before I realized you had posted those patches and also provided me with instructions. >>>> >>>> I am currently running wrapper version 3.5.17. I also saw that 3.5.26 appears to have the memory leak fixes in it (Based on reading the release notes). >>>> >>>> Which of the following would be the best option? >>>> >>>> Patch v3.5.17 >>>> Upgrade to v3.5.25 and patch >>>> Use v3.5.26 (Which I believe contains the fix I need) >>>> >>>> Obviously using 3.5.26 seems the simplest approach here, but I just wanted to double check with the community. >>>> >>>> Thanks, your help is much appreciated. >>>> >>>>> On Sat, Dec 20, 2014 at 6:46 PM, Casey Jordan <cas...@jo...> wrote: >>>>> Ok, so I have been monitoring for a bit now and I can definitely say that I have this memory leak and it is causing the issues I am experiencing. >>>>> >>>>> Now the issue remains that I do not believe that I can upgrade glibc on my system, given that all the threads I read say that will cause major problems. Also, I need to use CentOS 7 if at all possible. >>>>> >>>>> I noticed in the previously referenced thread that someone created a patch directly in the wrapper to also fix this issue, does anyone know if this fix made it into a release that I could use? >>>>> >>>>> Thanks! >> >> >> -- >> -- >> Casey Jordan >> easyDITA a product of Jorsek LLC >> "CaseyDJordan" on LinkedIn, Twitter & Facebook >> (585) 348 7399 >> easydita.com >> >> >> This message is intended only for the use of the Addressee(s) and may >> contain information that is privileged, confidential, and/or exempt from >> disclosure under applicable law. If you are not the intended recipient, >> please be advised that any disclosure copying, distribution, or use of >> the information contained herein is prohibited. If you have received >> this communication in error, please destroy all copies of the message, >> whether in electronic or hard copy format, as well as attachments, and >> immediately contact the sender by replying to this e-mail or by phone. >> Thank you. > > > > -- > -- > Casey Jordan > easyDITA a product of Jorsek LLC > "CaseyDJordan" on LinkedIn, Twitter & Facebook > (585) 348 7399 > easydita.com > > > This message is intended only for the use of the Addressee(s) and may > contain information that is privileged, confidential, and/or exempt from > disclosure under applicable law. If you are not the intended recipient, > please be advised that any disclosure copying, distribution, or use of > the information contained herein is prohibited. If you have received > this communication in error, please destroy all copies of the message, > whether in electronic or hard copy format, as well as attachments, and > immediately contact the sender by replying to this e-mail or by phone. > Thank you. > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Casey J. <cas...@jo...> - 2014-12-23 15:46:17
|
So I wanted to give an update on this. I created a simple stress testing script that triggered lots of logging to occur. I tested this on the 3.5.17 version and was easily able to see the memory leak as the wrapper process rose to about 3.5% (250MB) of memory usage over running this script for about 2 hours. However, now I am running this same script on 2.5.26, it's been running for about 30 min now and is already up to 1% system memory usage. I am going to keep running for a few hours and see what results I get. However, I am concerned because on non CentOs systems we never see the wrapper process even reach .1% consumption even after running for 6 months. Perhaps what I am seeing is just some artifact of something else (cache/buffers?)? Maybe there is a better way to test this before I put it back into production? (I don't really want to get into doing a valgrind session :) Thanks On Sun, Dec 21, 2014 at 10:27 PM, Casey Jordan <cas...@jo...> wrote: > Leif, > > Thanks for replying so quickly! That's great to hear, I'm excited to try > out the new version. > > > On Sunday, December 21, 2014, Leif Mortenson < > lei...@ta...> wrote: > >> Casey, >> Rather than patching the Wrapper, I would suggest the released version >> with the fix. There have been a number of other important improvements as >> well. >> We usually wait a couple weeks after a release before deciding to raise a >> version to stable. This is done to make sure that there are no unexpected >> errors reported from the user base. >> So far 3.5.26 has been quite stable. >> >> Cheers, >> Leif >> >> >> On Sun, Dec 21, 2014 at 9:52 AM, Casey Jordan <cas...@jo...> >> wrote: >>> >>> Hi Tim & Community, >>> >>> Sorry I had to go back and review your previous comments before I >>> realized you had posted those patches and also provided me with >>> instructions. >>> >>> I am currently running wrapper version 3.5.17. I also saw that 3.5.26 >>> appears to have the memory leak fixes in it (Based on reading the release >>> notes). >>> >>> Which of the following would be the best option? >>> >>> Patch v3.5.17 >>> Upgrade to v3.5.25 and patch >>> Use v3.5.26 (Which I believe contains the fix I need) >>> >>> Obviously using 3.5.26 seems the simplest approach here, but I just >>> wanted to double check with the community. >>> >>> Thanks, your help is much appreciated. >>> >>> On Sat, Dec 20, 2014 at 6:46 PM, Casey Jordan <cas...@jo...> >>> wrote: >>> >>>> Ok, so I have been monitoring for a bit now and I can definitely say >>>> that I have this memory leak and it is causing the issues I am experiencing. >>>> >>>> Now the issue remains that I do not believe that I can upgrade glibc on >>>> my system, given that all the threads I read say that will cause major >>>> problems. Also, I need to use CentOS 7 if at all possible. >>>> >>>> I noticed in the previously referenced thread that someone created a >>>> patch directly in the wrapper to also fix this issue, does anyone know if >>>> this fix made it into a release that I could use? >>>> >>>> Thanks! >>>> >>> >>> > > -- > -- > Casey Jordan > easyDITA a product of Jorsek LLC > "CaseyDJordan" on LinkedIn, Twitter & Facebook > (585) 348 7399 > easydita.com > > > This message is intended only for the use of the Addressee(s) and may > contain information that is privileged, confidential, and/or exempt from > disclosure under applicable law. If you are not the intended recipient, > please be advised that any disclosure copying, distribution, or use of > the information contained herein is prohibited. If you have received > this communication in error, please destroy all copies of the message, > whether in electronic or hard copy format, as well as attachments, and > immediately contact the sender by replying to this e-mail or by phone. > Thank you. > > -- -- Casey Jordan easyDITA a product of Jorsek LLC "CaseyDJordan" on LinkedIn, Twitter & Facebook (585) 348 7399 easydita.com This message is intended only for the use of the Addressee(s) and may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, please be advised that any disclosure copying, distribution, or use of the information contained herein is prohibited. If you have received this communication in error, please destroy all copies of the message, whether in electronic or hard copy format, as well as attachments, and immediately contact the sender by replying to this e-mail or by phone. Thank you. |
|
From: Casey J. <cas...@jo...> - 2014-12-22 03:28:02
|
Leif, Thanks for replying so quickly! That's great to hear, I'm excited to try out the new version. On Sunday, December 21, 2014, Leif Mortenson < lei...@ta...> wrote: > Casey, > Rather than patching the Wrapper, I would suggest the released version > with the fix. There have been a number of other important improvements as > well. > We usually wait a couple weeks after a release before deciding to raise a > version to stable. This is done to make sure that there are no unexpected > errors reported from the user base. > So far 3.5.26 has been quite stable. > > Cheers, > Leif > > > On Sun, Dec 21, 2014 at 9:52 AM, Casey Jordan <cas...@jo... > <javascript:_e(%7B%7D,'cvml','cas...@jo...');>> wrote: >> >> Hi Tim & Community, >> >> Sorry I had to go back and review your previous comments before I >> realized you had posted those patches and also provided me with >> instructions. >> >> I am currently running wrapper version 3.5.17. I also saw that 3.5.26 >> appears to have the memory leak fixes in it (Based on reading the release >> notes). >> >> Which of the following would be the best option? >> >> Patch v3.5.17 >> Upgrade to v3.5.25 and patch >> Use v3.5.26 (Which I believe contains the fix I need) >> >> Obviously using 3.5.26 seems the simplest approach here, but I just >> wanted to double check with the community. >> >> Thanks, your help is much appreciated. >> >> On Sat, Dec 20, 2014 at 6:46 PM, Casey Jordan <cas...@jo... >> <javascript:_e(%7B%7D,'cvml','cas...@jo...');>> wrote: >> >>> Ok, so I have been monitoring for a bit now and I can definitely say >>> that I have this memory leak and it is causing the issues I am experiencing. >>> >>> Now the issue remains that I do not believe that I can upgrade glibc on >>> my system, given that all the threads I read say that will cause major >>> problems. Also, I need to use CentOS 7 if at all possible. >>> >>> I noticed in the previously referenced thread that someone created a >>> patch directly in the wrapper to also fix this issue, does anyone know if >>> this fix made it into a release that I could use? >>> >>> Thanks! >>> >> >> -- -- Casey Jordan easyDITA a product of Jorsek LLC "CaseyDJordan" on LinkedIn, Twitter & Facebook (585) 348 7399 easydita.com This message is intended only for the use of the Addressee(s) and may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, please be advised that any disclosure copying, distribution, or use of the information contained herein is prohibited. If you have received this communication in error, please destroy all copies of the message, whether in electronic or hard copy format, as well as attachments, and immediately contact the sender by replying to this e-mail or by phone. Thank you. |
|
From: Leif M. <lei...@ta...> - 2014-12-22 01:52:00
|
Casey, Rather than patching the Wrapper, I would suggest the released version with the fix. There have been a number of other important improvements as well. We usually wait a couple weeks after a release before deciding to raise a version to stable. This is done to make sure that there are no unexpected errors reported from the user base. So far 3.5.26 has been quite stable. Cheers, Leif On Sun, Dec 21, 2014 at 9:52 AM, Casey Jordan <cas...@jo...> wrote: > > Hi Tim & Community, > > Sorry I had to go back and review your previous comments before I realized > you had posted those patches and also provided me with instructions. > > I am currently running wrapper version 3.5.17. I also saw that 3.5.26 > appears to have the memory leak fixes in it (Based on reading the release > notes). > > Which of the following would be the best option? > > Patch v3.5.17 > Upgrade to v3.5.25 and patch > Use v3.5.26 (Which I believe contains the fix I need) > > Obviously using 3.5.26 seems the simplest approach here, but I just wanted > to double check with the community. > > Thanks, your help is much appreciated. > > On Sat, Dec 20, 2014 at 6:46 PM, Casey Jordan <cas...@jo...> > wrote: > >> Ok, so I have been monitoring for a bit now and I can definitely say that >> I have this memory leak and it is causing the issues I am experiencing. >> >> Now the issue remains that I do not believe that I can upgrade glibc on >> my system, given that all the threads I read say that will cause major >> problems. Also, I need to use CentOS 7 if at all possible. >> >> I noticed in the previously referenced thread that someone created a >> patch directly in the wrapper to also fix this issue, does anyone know if >> this fix made it into a release that I could use? >> >> Thanks! >> > > |
|
From: Casey J. <cas...@jo...> - 2014-12-21 00:53:00
|
Hi Tim & Community, Sorry I had to go back and review your previous comments before I realized you had posted those patches and also provided me with instructions. I am currently running wrapper version 3.5.17. I also saw that 3.5.26 appears to have the memory leak fixes in it (Based on reading the release notes). Which of the following would be the best option? Patch v3.5.17 Upgrade to v3.5.25 and patch Use v3.5.26 (Which I believe contains the fix I need) Obviously using 3.5.26 seems the simplest approach here, but I just wanted to double check with the community. Thanks, your help is much appreciated. On Sat, Dec 20, 2014 at 6:46 PM, Casey Jordan <cas...@jo...> wrote: > Ok, so I have been monitoring for a bit now and I can definitely say that > I have this memory leak and it is causing the issues I am experiencing. > > Now the issue remains that I do not believe that I can upgrade glibc on my > system, given that all the threads I read say that will cause major > problems. Also, I need to use CentOS 7 if at all possible. > > I noticed in the previously referenced thread that someone created a patch > directly in the wrapper to also fix this issue, does anyone know if this > fix made it into a release that I could use? > > Thanks! > -- -- Casey Jordan easyDITA a product of Jorsek LLC "CaseyDJordan" on LinkedIn, Twitter & Facebook (585) 348 7399 easydita.com This message is intended only for the use of the Addressee(s) and may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, please be advised that any disclosure copying, distribution, or use of the information contained herein is prohibited. If you have received this communication in error, please destroy all copies of the message, whether in electronic or hard copy format, as well as attachments, and immediately contact the sender by replying to this e-mail or by phone. Thank you. |
165 messages has been excluded from this view by a project administrator.
