IOS builds failing, June 10
53 views
Skip to first unread message
Dave Dyer
Jun 11, 2017, 3:05:08 AM6/11/17
to CodenameOne Discussions
No useful info in the error log, but it looks like the previous timeout kills, but the time to death is only a few minutes.
4x so far
My most recent successful build was yesterday.
4x so far
My most recent successful build was yesterday.
Shai Almog
Jun 11, 2017, 11:57:14 PM6/11/17
to CodenameOne Discussions
We didn't change anything. We've been too busy.
Dave Dyer
Jun 12, 2017, 1:08:41 PM6/12/17
to CodenameOne Discussions
This is somewhere between odd and alarming. The next morning, all seems
to be well. With no one having changed anything, it's a mystery.
The failed builds looked exactly like the builds killed for exceeding a time limit - the
logs stop after the parse phase, in what would have been the cleanup-and-write
phase, except that the kill occurred very quicky.
The successful builds are back to the now-typical 10 minute time for a dev build.
It would be very useful to see the logs for the corresponding successful builds.. Why aren't they available?
to be well. With no one having changed anything, it's a mystery.
The failed builds looked exactly like the builds killed for exceeding a time limit - the
logs stop after the parse phase, in what would have been the cleanup-and-write
phase, except that the kill occurred very quicky.
The successful builds are back to the now-typical 10 minute time for a dev build.
It would be very useful to see the logs for the corresponding successful builds.. Why aren't they available?
Shai Almog
Jun 13, 2017, 12:38:48 AM6/13/17
to CodenameOne Discussions
This is something that only happens to your apps.
Providing a log to successful builds is problematic and would slow down our builds overall.
Providing a log to successful builds is problematic and would slow down our builds overall.
Dave Dyer
Jun 13, 2017, 3:20:22 PM6/13/17
to CodenameOne Discussions
Speed isn't everything. Today this "mystery kill" is occurring with 50% probability. The CPU time wasted is enormous.
You have to generate the complete log anyway, all you have to do is save it instead of delete it.
You have to generate the complete log anyway, all you have to do is save it instead of delete it.
Dave Dyer
Jun 13, 2017, 5:02:49 PM6/13/17
to CodenameOne Discussions
Today's revised failure probability seems to be 100% for production builds. Behavior is
consistent with a timeout at 11 minutes. My prod builds current require about 16
minutes; one was successful yesterday.
BTW, my push request that speeds up this process is still pending.
Shai Almog
Jun 14, 2017, 12:23:55 AM6/14/17
to CodenameOne Discussions
No we have to upload it to the storage server which is an additional cost and we need to write code to do that and display that both of which aren't there.
I've pinged Steve about this I'm not sure where it stands.
I've pinged Steve about this I'm not sure where it stands.
Steve Hannah
Jun 14, 2017, 12:49:29 PM6/14/17
to codenameone...@googlegroups.com
I haven't had a chance to merge it yet. I've been busy with issues targeted for the 3.7 release. Merging this will require some time as I need to ensure that it doesn't introduce any regressions (the last pull request was much smaller, and still a regression slipped through). I'll have more time to look into this after the 3.7 release is done and I'm done with the new GUI builder modifications. Before the 3.8 release.
From my perspective, the contents of the pull request don't present much up-side as for most apps there would be no performance increase and even with your apps, after we increased the heap size, it likely wouldn't affect performance much (correct me if I'm wrong). And the down-side is that it could introduce bugs that don't exist now. Therefore I feel a low urgency on this one. That "priority" can be changed if Shai or Chen disagree with my assessment - or if you can make a compelling case for it being more urgent.
Steve
On Tue, Jun 13, 2017 at 9:23 PM, Shai Almog <shai....@gmail.com> wrote:
No we have to upload it to the storage server which is an additional cost and we need to write code to do that and display that both of which aren't there.
I've pinged Steve about this I'm not sure where it stands.
--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/f205f694-63b7-4768-8d1c-0c8fb67adf8e%40googlegroups.com.
Dave Dyer
Jun 14, 2017, 1:11:33 PM6/14/17
to CodenameOne Discussions
There are two different pull requests, one fixes the "statement expected" bug and reduces memory usage, so is
a modest incremental improvement in performance. The other replaces the is-method-used mechanism and
would remove about 2 minutes from my builds. 2 from 10 is not a bad improvement. I appreciate the need
to regress these carefully.
Dave Dyer
Jun 14, 2017, 1:14:14 PM6/14/17
to CodenameOne Discussions
The mechanism to preserve and display log files is there, it kicks in when the build
fails. The size of log files is trivial compared to the application itself.
fails. The size of log files is trivial compared to the application itself.
Shai Almog
Jun 15, 2017, 12:17:59 AM6/15/17
to CodenameOne Discussions
Not how it works. Error is always error. Response is always response. Different things.
Reply all
Reply to author
Forward
0 new messages