Re: AWS has surrendered!

2016-10-24 Thread Paul Hoadley
Hi Flavio,

On 25 Oct 2016, at 1:06 AM, Flavio Donadio  wrote:

> Paul: if you can share that updated script, it would be nice.

The modifications largely relate to the specifics of our infrastructure setup 
(where various artifacts come from, how to retrieve the app bundles, and so 
on), so it wouldn’t be widely useful. If anyone has any particular issues, 
whether they’re EC2-, Amazon Linux- or simply Unix-related, please post them 
and we can definitely work them through.


-- 
Paul Hoadley
http://logicsquad.net/




 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NPE in ERXObjectStoreCoordinatorSynchronizer

2016-10-24 Thread Chuck Hill
Looks like eo.editingContext() == null  but beyond that…


From:  on behalf of 
Paul Hoadley 
Date: Monday, October 24, 2016 at 3:45 PM
To: WebObjects Development 
Subject: Re: NPE in ERXObjectStoreCoordinatorSynchronizer

On 19 Oct 2016, at 1:12 PM, Paul Hoadley 
> wrote:

Oct 17 23:10:57 Relief[2002] ERROR 
er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer  - 
java.lang.NullPointerException
NullPointerException
  at 
com.webobjects.eocontrol.EOCustomObject.willReadRelationship(EOCustomObject.java:1270)
  at 
er.extensions.eof.ERXGenericRecord.willReadRelationship(ERXGenericRecord.java:385)
  at 
com.webobjects.eocontrol._EOMutableKnownKeyDictionary$Initializer$_LazyGenericRecordBinding.valueInObject(_EOMutableKnownKeyDictionary.java:614)
  at 
er.extensions.eof.ERXGenericRecord$TouchingBinding.valueInObject(ERXGenericRecord.java:214)
  at 
com.webobjects.eocontrol.EOCustomObject.storedValueForKey(EOCustomObject.java:1634)
  at net.logicsquad.relief.model._Job.classTeacher(_Job.java:192)
 ... skipped 6 stack elements
  at 
er.extensions.eof.ERXGenericRecord$InverseRelationshipUpdater.includeObjectIntoPropertyWithKey(ERXGenericRecord.java:1367)
  at 
er.extensions.eof.ERXGenericRecord.includeObjectIntoPropertyWithKey(ERXGenericRecord.java:1225)
  at net.logicsquad.relief.model._ClassTeacher.addToJobs(_ClassTeacher.java:212)
 ... skipped 5 stack elements
  at 
com.webobjects.eocontrol.EOCustomObject.addObjectToPropertyWithKey(EOCustomObject.java:940)
  at 
com.webobjects.eocontrol.EOEditingContext._mergeValueForKey(EOEditingContext.java:660)
  at 
com.webobjects.eocontrol.EOEditingContext._mergeObjectWithChanges(EOEditingContext.java:3457)
  at 
com.webobjects.eocontrol.EOEditingContext._processObjectStoreChanges(EOEditingContext.java:3546)
  at er.extensions.eof.ERXEC._processObjectStoreChanges(ERXEC.java:1549)
 ... skipped 5 stack elements
  at 
com.webobjects.eocontrol.EOEditingContext._sendOrEnqueueNotification(EOEditingContext.java:4715)
  at 
com.webobjects.eocontrol.EOEditingContext._objectsChangedInStore(EOEditingContext.java:3562)
  at er.extensions.eof.ERXEC._objectsChangedInStore(ERXEC.java:1489)
 ... skipped 7 stack elements
  at 
com.webobjects.eocontrol.EOObjectStoreCoordinator._objectsChangedInSubStore(EOObjectStoreCoordinator.java:693)
 ... skipped 7 stack elements
  at 
er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueue$ToManyUpdateCacheChangeProcessor.processCacheChange(ERXObjectStoreCoordinatorSynchronizer.java:466)
  at 
er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueue.processRemoteChange(ERXObjectStoreCoordinatorSynchronizer.java:566)
  at 
er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueue.run(ERXObjectStoreCoordinatorSynchronizer.java:622)
  ... skipped 1 stack elements

Does anyone want to take a guess at this one?

Come on, I know you want to.


--
Paul Hoadley
http://logicsquad.net/




 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NPE in ERXObjectStoreCoordinatorSynchronizer

2016-10-24 Thread Paul Hoadley
On 19 Oct 2016, at 1:12 PM, Paul Hoadley  wrote:

> Oct 17 23:10:57 Relief[2002] ERROR 
> er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer  - 
> java.lang.NullPointerException
> NullPointerException
>   at 
> com.webobjects.eocontrol.EOCustomObject.willReadRelationship(EOCustomObject.java:1270)
>   at 
> er.extensions.eof.ERXGenericRecord.willReadRelationship(ERXGenericRecord.java:385)
>   at 
> com.webobjects.eocontrol._EOMutableKnownKeyDictionary$Initializer$_LazyGenericRecordBinding.valueInObject(_EOMutableKnownKeyDictionary.java:614)
>   at 
> er.extensions.eof.ERXGenericRecord$TouchingBinding.valueInObject(ERXGenericRecord.java:214)
>   at 
> com.webobjects.eocontrol.EOCustomObject.storedValueForKey(EOCustomObject.java:1634)
>   at net.logicsquad.relief.model._Job.classTeacher(_Job.java:192)
>  ... skipped 6 stack elements
>   at 
> er.extensions.eof.ERXGenericRecord$InverseRelationshipUpdater.includeObjectIntoPropertyWithKey(ERXGenericRecord.java:1367)
>   at 
> er.extensions.eof.ERXGenericRecord.includeObjectIntoPropertyWithKey(ERXGenericRecord.java:1225)
>   at 
> net.logicsquad.relief.model._ClassTeacher.addToJobs(_ClassTeacher.java:212)
>  ... skipped 5 stack elements
>   at 
> com.webobjects.eocontrol.EOCustomObject.addObjectToPropertyWithKey(EOCustomObject.java:940)
>   at 
> com.webobjects.eocontrol.EOEditingContext._mergeValueForKey(EOEditingContext.java:660)
>   at 
> com.webobjects.eocontrol.EOEditingContext._mergeObjectWithChanges(EOEditingContext.java:3457)
>   at 
> com.webobjects.eocontrol.EOEditingContext._processObjectStoreChanges(EOEditingContext.java:3546)
>   at er.extensions.eof.ERXEC._processObjectStoreChanges(ERXEC.java:1549)
>  ... skipped 5 stack elements
>   at 
> com.webobjects.eocontrol.EOEditingContext._sendOrEnqueueNotification(EOEditingContext.java:4715)
>   at 
> com.webobjects.eocontrol.EOEditingContext._objectsChangedInStore(EOEditingContext.java:3562)
>   at er.extensions.eof.ERXEC._objectsChangedInStore(ERXEC.java:1489)
>  ... skipped 7 stack elements
>   at 
> com.webobjects.eocontrol.EOObjectStoreCoordinator._objectsChangedInSubStore(EOObjectStoreCoordinator.java:693)
>  ... skipped 7 stack elements
>   at 
> er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueue$ToManyUpdateCacheChangeProcessor.processCacheChange(ERXObjectStoreCoordinatorSynchronizer.java:466)
>   at 
> er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueue.processRemoteChange(ERXObjectStoreCoordinatorSynchronizer.java:566)
>   at 
> er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueue.run(ERXObjectStoreCoordinatorSynchronizer.java:622)
>   ... skipped 1 stack elements

> Does anyone want to take a guess at this one?

Come on, I know you want to.


-- 
Paul Hoadley
http://logicsquad.net/



 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: which sort of application bugs hang wotaskd?

2016-10-24 Thread o...@ocs.cz
Thanks a lot both!

(weird, I would have bet wotaskd is designed to survive and detect and 
potentially even relaunch frozen apps, but well, my memory self-evidently plays 
ugly tricks on me.)

Anyway...

> On 24. 10. 2016, at 6:23 PM, Chuck Hill  wrote:
> This should explain the how and why (IIRC) 
> http://www.podcastchart.com/podcasts/webobjects-podcasts/episodes/wotaskd-internals-bringing-sanity-to-deployment

... I would not like to sound ungrateful, but might perhaps there be somewhere 
something similar in a written form? Thing is, English is not my native 
language, and whilst I succeeded to read pretty well, my listening abilities 
are, alas, quite another story :(
 
> And offer some fixes and improvements.  And like most (all?) of my WOWODC 
> presentations, never fully finished. 
> As for the hang, the code in the logging does seem like a likely culprit.  
> Running “sudo jstack –F ” should dump a trace of all threads.  
> Should… 

Thanks a lot, I'll ask the site admit to try, if the darned this happens again.

All the best,
OC

> From:  on behalf 
> of OC 
> Date: Monday, October 24, 2016 at 8:41 AM
> To: WebObjects-Dev 
> Subject: which sort of application bugs hang wotaskd?
>  
> Hello there,
>  
> there seems to be one pretty rare, ugly and hard-to find lock in my 
> application (I shall get back to it at the end, in hope it might ring a 
> bell), but what's most weird: it seems that when it happens, it's _wotaskd_ 
> what primarily goes down?!?
>  
> Alas, the information is sparse: it is the deployment site, to where the 
> programming team has no access (and so far we were not able to repeat the 
> problem at the test site whatever we try), but due to the site admin and 
> logs, it looks like
>  
> (a) first, one of the worker threads hangs somehow, so far inexplicably (EC 
> locking problem possible but improbable, explained below)
> (b) for some time, other threads run without a glitch, new reqeusts are 
> served, new R/R loop worker threads are spawned and logged (I log out all R/R 
> loops)
> (c) shortly (in minutes) though the adaptor begins to redirect requests to 
> the “Redirection URL”
> (d) now, the site admin is alerted; he runs JavaMonitor **which reports 
> “Failed to contact 127.0.0.1-1085”**!
> (e) he finds which process belongs to *the application instance* (*not* the 
> wotaskd!), and kills it from Terminal
> (f) which causes wotaskd to magically cure and JavaMonitor starts working and 
> stops showing the 1085 fail, allows to re-launch the instance, all is well 
> and swell.
>  
> Does this perhaps ring a bell? To me this behaviour does not make any sense :/
>  
> As for the hang itself, it's rather weird too. There is a loop which goes 
> through a list of EOs; each of them is logged out. Something like this:
>  
> ===
> for (DBTimeChunk tch in session().currentMarket.orderedTimeChunks()) {
> log.info(""+tch)
> if (tch.someTimestamp>fixedTimestamp) continue // happens to be 
> true in our case
> ... therefore some irrelevant code here (it would log if it 
> happened, does not) ...
> }
> ===
>  
> The problem is that
>  
> - this goes through some of the TimeChunks, and _then_ it hangs -- not at the 
> start of R/R loop, where EC locking problems could be expected
> - in the same session, with the same EC, even in the same thread (for the 
> method which contains the loop happens to be used twice in the page template) 
> the loop already run through all the TimeChunks and tested their 
> someTimestamp and ended without a glitch (so, no fault is fired when it hangs)
>  
> So far it happened about thrice; each time on different TimeChunk.
>  
> About the only thing I guess _might_ cause the hang of the thread is the "log 
> tch". TimeChunk's toString() is comparatively complex, it might call, among 
> more mundane things, also
> - this.changesFromCommittedSnapshot()
> - this.attributeKeys()
> - this.primaryKey() (of ERXGenericRecord which it inherits)
>  
> Might one of them hang the thread, if another thread does the same/something 
> other at the wrong moment? (Presumed all of them were already called for the 
> same EO in the same thread all right shortly ago.)
>  
> If it happens again, it would help if the site admin could, before killing 
> the application, to force it somehow to log the stacktracks of all its 
> threads. Is there some trick for that?
>  
> And of course, for any other advice how to hunt for this bloody kind of bug 
> I'll be extremely grateful.
>  
> Thanks a lot,
> OC
>  
>  
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> 

Re: which sort of application bugs hang wotaskd?

2016-10-24 Thread Chuck Hill
This should explain the how and why (IIRC) 
http://www.podcastchart.com/podcasts/webobjects-podcasts/episodes/wotaskd-internals-bringing-sanity-to-deployment

And offer some fixes and improvements.  And like most (all?) of my WOWODC 
presentations, never fully finished.

As for the hang, the code in the logging does seem like a likely culprit.  
Running “sudo jstack –F ” should dump a trace of all threads.  
Should…


Chuck

From:  on behalf of 
OC 
Date: Monday, October 24, 2016 at 8:41 AM
To: WebObjects-Dev 
Subject: which sort of application bugs hang wotaskd?

Hello there,

there seems to be one pretty rare, ugly and hard-to find lock in my application 
(I shall get back to it at the end, in hope it might ring a bell), but what's 
most weird: it seems that when it happens, it's _wotaskd_ what primarily goes 
down?!?

Alas, the information is sparse: it is the deployment site, to where the 
programming team has no access (and so far we were not able to repeat the 
problem at the test site whatever we try), but due to the site admin and logs, 
it looks like

(a) first, one of the worker threads hangs somehow, so far inexplicably (EC 
locking problem possible but improbable, explained below)
(b) for some time, other threads run without a glitch, new reqeusts are served, 
new R/R loop worker threads are spawned and logged (I log out all R/R loops)
(c) shortly (in minutes) though the adaptor begins to redirect requests to the 
“Redirection URL”
(d) now, the site admin is alerted; he runs JavaMonitor **which reports “Failed 
to contact 127.0.0.1-1085”**!
(e) he finds which process belongs to *the application instance* (*not* the 
wotaskd!), and kills it from Terminal
(f) which causes wotaskd to magically cure and JavaMonitor starts working and 
stops showing the 1085 fail, allows to re-launch the instance, all is well and 
swell.

Does this perhaps ring a bell? To me this behaviour does not make any sense :/

As for the hang itself, it's rather weird too. There is a loop which goes 
through a list of EOs; each of them is logged out. Something like this:

===
for (DBTimeChunk tch in session().currentMarket.orderedTimeChunks()) {
log.info(""+tch)
if (tch.someTimestamp>fixedTimestamp) continue // happens to be 
true in our case
... therefore some irrelevant code here (it would log if it 
happened, does not) ...
}
===

The problem is that

- this goes through some of the TimeChunks, and _then_ it hangs -- not at the 
start of R/R loop, where EC locking problems could be expected
- in the same session, with the same EC, even in the same thread (for the 
method which contains the loop happens to be used twice in the page template) 
the loop already run through all the TimeChunks and tested their someTimestamp 
and ended without a glitch (so, no fault is fired when it hangs)

So far it happened about thrice; each time on different TimeChunk.

About the only thing I guess _might_ cause the hang of the thread is the "log 
tch". TimeChunk's toString() is comparatively complex, it might call, among 
more mundane things, also
- this.changesFromCommittedSnapshot()
- this.attributeKeys()
- this.primaryKey() (of ERXGenericRecord which it inherits)

Might one of them hang the thread, if another thread does the same/something 
other at the wrong moment? (Presumed all of them were already called for the 
same EO in the same thread all right shortly ago.)

If it happens again, it would help if the site admin could, before killing the 
application, to force it somehow to log the stacktracks of all its threads. Is 
there some trick for that?

And of course, for any other advice how to hunt for this bloody kind of bug 
I'll be extremely grateful.

Thanks a lot,
OC


___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  
(Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com

This email sent to ch...@gevityinc.com
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: which sort of application bugs hang wotaskd?

2016-10-24 Thread Michael Kondratov
WOTaskd will become unresponsive whenever an instance hangs. We’ve reconfigured 
WOTaskd to write the configuration into XML file and Apache adapter reads it 
instead of communicating with wotaskd directly.

Michael Kondratov
Aspire Auctions, Inc.
216-231-5515

> On Oct 24, 2016, at 11:41 AM, OC  wrote:
> 
> Hello there,
> 
> there seems to be one pretty rare, ugly and hard-to find lock in my 
> application (I shall get back to it at the end, in hope it might ring a 
> bell), but what's most weird: it seems that when it happens, it's _wotaskd_ 
> what primarily goes down?!?
> 
> Alas, the information is sparse: it is the deployment site, to where the 
> programming team has no access (and so far we were not able to repeat the 
> problem at the test site whatever we try), but due to the site admin and 
> logs, it looks like
> 
> (a) first, one of the worker threads hangs somehow, so far inexplicably (EC 
> locking problem possible but improbable, explained below)
> (b) for some time, other threads run without a glitch, new reqeusts are 
> served, new R/R loop worker threads are spawned and logged (I log out all R/R 
> loops)
> (c) shortly (in minutes) though the adaptor begins to redirect requests to 
> the “Redirection URL”
> (d) now, the site admin is alerted; he runs JavaMonitor **which reports 
> “Failed to contact 127.0.0.1-1085”**!
> (e) he finds which process belongs to *the application instance* (*not* the 
> wotaskd!), and kills it from Terminal
> (f) which causes wotaskd to magically cure and JavaMonitor starts working and 
> stops showing the 1085 fail, allows to re-launch the instance, all is well 
> and swell.
> 
> Does this perhaps ring a bell? To me this behaviour does not make any sense :/
> 
> As for the hang itself, it's rather weird too. There is a loop which goes 
> through a list of EOs; each of them is logged out. Something like this:
> 
> ===
>for (DBTimeChunk tch in session().currentMarket.orderedTimeChunks()) {
>log.info(""+tch)
>if (tch.someTimestamp>fixedTimestamp) continue // happens to be 
> true in our case
>... therefore some irrelevant code here (it would log if it 
> happened, does not) ...
>}
> ===
> 
> The problem is that
> 
> - this goes through some of the TimeChunks, and _then_ it hangs -- not at the 
> start of R/R loop, where EC locking problems could be expected
> - in the same session, with the same EC, even in the same thread (for the 
> method which contains the loop happens to be used twice in the page template) 
> the loop already run through all the TimeChunks and tested their 
> someTimestamp and ended without a glitch (so, no fault is fired when it hangs)
> 
> So far it happened about thrice; each time on different TimeChunk.
> 
> About the only thing I guess _might_ cause the hang of the thread is the "log 
> tch". TimeChunk's toString() is comparatively complex, it might call, among 
> more mundane things, also
> - this.changesFromCommittedSnapshot()
> - this.attributeKeys()
> - this.primaryKey() (of ERXGenericRecord which it inherits)
> 
> Might one of them hang the thread, if another thread does the same/something 
> other at the wrong moment? (Presumed all of them were already called for the 
> same EO in the same thread all right shortly ago.)
> 
> If it happens again, it would help if the site admin could, before killing 
> the application, to force it somehow to log the stacktracks of all its 
> threads. Is there some trick for that?
> 
> And of course, for any other advice how to hunt for this bloody kind of bug 
> I'll be extremely grateful.
> 
> Thanks a lot,
> OC
> 
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/michael%40aspireauctions.com
> 
> This email sent to mich...@aspireauctions.com


 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

which sort of application bugs hang wotaskd?

2016-10-24 Thread OC
Hello there,

there seems to be one pretty rare, ugly and hard-to find lock in my application 
(I shall get back to it at the end, in hope it might ring a bell), but what's 
most weird: it seems that when it happens, it's _wotaskd_ what primarily goes 
down?!?

Alas, the information is sparse: it is the deployment site, to where the 
programming team has no access (and so far we were not able to repeat the 
problem at the test site whatever we try), but due to the site admin and logs, 
it looks like

(a) first, one of the worker threads hangs somehow, so far inexplicably (EC 
locking problem possible but improbable, explained below)
(b) for some time, other threads run without a glitch, new reqeusts are served, 
new R/R loop worker threads are spawned and logged (I log out all R/R loops)
(c) shortly (in minutes) though the adaptor begins to redirect requests to the 
“Redirection URL”
(d) now, the site admin is alerted; he runs JavaMonitor **which reports “Failed 
to contact 127.0.0.1-1085”**!
(e) he finds which process belongs to *the application instance* (*not* the 
wotaskd!), and kills it from Terminal
(f) which causes wotaskd to magically cure and JavaMonitor starts working and 
stops showing the 1085 fail, allows to re-launch the instance, all is well and 
swell.

Does this perhaps ring a bell? To me this behaviour does not make any sense :/

As for the hang itself, it's rather weird too. There is a loop which goes 
through a list of EOs; each of them is logged out. Something like this:

===
for (DBTimeChunk tch in session().currentMarket.orderedTimeChunks()) {
log.info(""+tch)
if (tch.someTimestamp>fixedTimestamp) continue // happens to be 
true in our case
... therefore some irrelevant code here (it would log if it 
happened, does not) ...
}
===

The problem is that

- this goes through some of the TimeChunks, and _then_ it hangs -- not at the 
start of R/R loop, where EC locking problems could be expected
- in the same session, with the same EC, even in the same thread (for the 
method which contains the loop happens to be used twice in the page template) 
the loop already run through all the TimeChunks and tested their someTimestamp 
and ended without a glitch (so, no fault is fired when it hangs)

So far it happened about thrice; each time on different TimeChunk.

About the only thing I guess _might_ cause the hang of the thread is the "log 
tch". TimeChunk's toString() is comparatively complex, it might call, among 
more mundane things, also
- this.changesFromCommittedSnapshot()
- this.attributeKeys()
- this.primaryKey() (of ERXGenericRecord which it inherits)

Might one of them hang the thread, if another thread does the same/something 
other at the wrong moment? (Presumed all of them were already called for the 
same EO in the same thread all right shortly ago.)

If it happens again, it would help if the site admin could, before killing the 
application, to force it somehow to log the stacktracks of all its threads. Is 
there some trick for that?

And of course, for any other advice how to hunt for this bloody kind of bug 
I'll be extremely grateful.

Thanks a lot,
OC


 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: AWS has surrendered!

2016-10-24 Thread Flavio Donadio
Ted and Paul,


Thanks for the information. I never deployed on Amazon, but I will, definitely. 
Maybe sooner than I think, so the info will be very important.

Paul: if you can share that updated script, it would be nice.


Cheers,
Flavio

> On 23 Oct 2016, at 12:30, Theodore Petrosky  wrote:
> 
> I feel I have a grip on what is going on!! I followed the wiki mostly, but 
> there were problems.
> 
> anyway, on the wiki Deploying on Amazon EC2 there is a link to install a 
> “Hello World Walkthrough”
> 
> trying to make it work failed :(
> 
> but in taking apart the install scripts I found this
> wget http://webobjects.s3.amazonaws.com/wo-install.sh 
> 
> I downloaded it, took it apart and modified it to install a newer version of 
> JavaMonitor and wotaskd and mod_WebObjects.so
> 
> Examining that wo-install.sh was the key for me to understand what is going 
> on and ultimately get mine going.
> 
> let me know if you get it going!!! I am really impressed with the response. I 
> actually feel it is on par with running it locally (maybe even snappier).
> 
> security seems good. your instance runs on an internal IP and you attach an 
> Elastic IP (static). you can set security to only allow traffic on port 80 
> and 443 and in my case I added port 56789 from my IP only.
> 
> Ted
> 
> 
> 
>> On Oct 22, 2016, at 4:57 PM, Flavio Donadio  wrote:
>> 
>> Theodore,
>> 
>> 
>> Congratulations!
>> 
>> I don’t know if you followed a how-to or tutorial and, if so, I would like 
>> to know which one. I’m pretty dure you encountered some problems and would 
>> also like to know how you solved ‘em.
>> 
>> 
>> Cheers,
>> Flavio
>> 
>>> On 22 Oct 2016, at 14:48, Theodore Petrosky  wrote:
>>> 
>>> I finally got it. 
>>> 
>>> My first WO D2W app in a free Amazon Web Service EC2 instance. Now I can 
>>> spend some time re-documenting this so I can do it again.
>>> 
>>> I have to say, that I am really impressed with the overall responsiveness 
>>> of the setup. it really is quite fast. I feel the app is more responsive 
>>> than when I was playing on RackSpace.
>>> ___
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/flavio%40donadio.com.br
>>> 
>>> This email sent to fla...@donadio.com.br
>> 
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/tedpet5%40yahoo.com
>> 
>> This email sent to tedp...@yahoo.com
> 


 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: AWS has surrendered!

2016-10-24 Thread Paul Hoadley
Hi Ted,

On 24 Oct 2016, at 1:00 AM, Theodore Petrosky  wrote:

> I feel I have a grip on what is going on!! I followed the wiki mostly, but 
> there were problems.

Congratulations.

Can you list the wiki page(s) you were following, and the problems you 
encountered? Maybe we could update them.

> anyway, on the wiki Deploying on Amazon EC2 there is a link to install a 
> “Hello World Walkthrough”
> 
> trying to make it work failed :(
> 
> but in taking apart the install scripts I found this
> wget http://webobjects.s3.amazonaws.com/wo-install.sh 
>  

If I recall correctly, that’s some rather old work from Simon McLean—but that’s 
where I started as well. To this day, we still deploy our apps with a (now 
heavily modified) version of that script.

> security seems good. your instance runs on an internal IP and you attach an 
> Elastic IP (static). you can set security to only allow traffic on port 80 
> and 443 and in my case I added port 56789 from my IP only.

That’s a good idea, though if your IP address isn’t static, you can avoid 
constantly changing the security group by tunnelling over SSH:

$ ssh -L 56789:localhost:56789 ec2-u...@your.ec2.host.name 


That will tunnel local 56789 over SSH to the remote’s 56789, security group 
doesn’t need to know anything about it. JavaMonitor is then at:

http://localhost:56789/ 


-- 
Paul Hoadley
http://logicsquad.net/



 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com