April 2013 - Webobjects-dev

Golipse 3.8.2 update and pull request
by Tim Worman 30 Apr '13

30 Apr '13

I updated Golipse in my branch and submitted a pull request to wocommunity/Golipse. The pull request indicates "no one is assigned" - so I'm guessing that means it won't be applied without a nudge. :-) Maybe someone with commit rights on wocommunity can review and pull it in? https://github.com/wocommunity/Golipse/pull/16 Tim _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: I got stuck while trying to deploy a WebObjects based application (Web-CAT)
by Filippo Laurìa 30 Apr '13

30 Apr '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: EOF related objects present a lot in the heap
by Chuck Hill 29 Apr '13

29 Apr '13

On 2013-04-29, at 2:11 AM, Musall Maik wrote: > > Am 26.04.2013 um 21:21 schrieb Chuck Hill <chill(a)global-village.net>: > >> >> On 2013-04-26, at 12:12 PM, Ramsey Gurley wrote: >>> Disadvantages of persistent sessions: >>> >>> * Hard. Everything must be serializable on your session. Your EOs, your WOComponents, everything. Fixing serialization errors is no walk in the park. >>> * Serialization adds a few milliseconds wait to the RR loop. >>> * Database load. Every RR loop is two selects and an update on a session row. Even if you isolate the session in their own database, there's a wall there. Get large enough and you'll hit it. Postgres 9.2 can handle about 14,000 writes per second according to what I've read. >> >> memcached, or something like that, might be an interesting alternative. > > What would be the point of freeing some memory in WO only to allocate the same memory in another process? I was considering how to make persistent sessions faster, not save memory. -- Chuck Hill Executive Managing Partner, VP Development and Technical Services Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/gvc/practical_webobjects Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest Growing Companies in B.C! Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of Canada’s Fastest-Growing Companies by PROFIT Magazine! _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: I got stuck while trying to deploy a WebObjects based application (Web-CAT)
by Jesse Tayler 29 Apr '13

29 Apr '13

well, I don't know but your entry point is a cgi-bin call to a direct action called "default", at least from what I recall - so, one might ask if you can access this URL directly or if there is any obvious reason that you'd not be able to access that directory maybe? doesn't sound like your app is being hit at all by what you describe. On Apr 29, 2013, at 5:41 PM, Filippo Laurìa <filippo.lauria1(a)gmail.com> wrote: > Hi everyone, > as you can read from subject I got stuck while trying to deploy Web-CAT on my Ubuntu 12.10 + Tomcat7. > > Before I start talking about the problem, let's say that my environment is based on Eclipse + WebObjects 543 + Project Wonder Frameworks. > > Web-CAT sources are a bunch of Eclipse projects: there's no instruction on how to build them, so after searching a little, I found an Ant build.xml file into Web-CAT project. Easy, I thought. > > I was wrong, but after some tries I was able to build a war deployable file. > > When I put this into my tomcat's webroot I had a problem on deployment that is well described here [1]. I think I solved this modifying web.xml file according to this article [2]. > > Now Tomcat can deploy my war, but when trying to access default first page of the application (Login Page) I encounter a 404 Tomcat's standard HTTP error page. > > It seems that "entry point" (sorry for non-technical terms) is missing. > > What do you think about it? > > Thanks for answering. > > Greetings. > > [1]: http://stackoverflow.com/questions/16286781/cannot-deploy-web-cat-a-webobje… > [2]: http://wiki.wocommunity.org/display/WO/Creating+a+wonder+app+to+deploy+as+a… > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com > > This email sent to jtayler(a)oeinc.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

I got stuck while trying to deploy a WebObjects based application (Web-CAT)
by Filippo Laurìa 29 Apr '13

29 Apr '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: EOF related objects present a lot in the heap
by Musall Maik 29 Apr '13

29 Apr '13

Am 29.04.2013 um 17:49 schrieb Ramsey Gurley <ramseygurley(a)gmail.com>: >>> Advantages of persistent sessions: >>> >>> * Frees memory at the end of the RR loop >>> * Easier to manage deployments. Sessions are distributed across instances. >>> * Sessions can last as long as you want. >>> >>> Disadvantages of persistent sessions: >>> >>> * Hard. Everything must be serializable on your session. Your EOs, your WOComponents, everything. Fixing serialization errors is no walk in the park. >>> * Serialization adds a few milliseconds wait to the RR loop. >>> * Database load. Every RR loop is two selects and an update on a session row. Even if you isolate the session in their own database, there's a wall there. Get large enough and you'll hit it. Postgres 9.2 can handle about 14,000 writes per second according to what I've read. >> >> Do you think it would be possible to not serialize out the session on each RR loop, but instead having a short timeout delay (like 10 or 30 seconds), make the session persistent once the timeout is reached, and keeping the actively used sessions in memory? >> >> Could that be "best of both worlds"? :-) Of course you wouldn't spare the serialization debugging. >> >> Maik > > If you retain sessions in memory, even for a little while, you lose the second advantage: session distribution. That is just as important to me as the memory savings because it allows for horizontal scaling across commodity machines. Applications under heavy load? Just add more instances. We're already adding instances when needed for load distribution. But we don't have that load problem unless we also have so many sessions that distributing whole running sessions between instances solves it. I don't really see the need for sessions to walk across instances between RR loops, at least not for what we're doing (but I don't know all of our projects in detail). Still sounds interesting, I'm just having a hard time to imagine it useful in production. It just solves problems we didn't have until now. > You'll never hit the wall on the apps. Only on the database. Even with the database, I doubt it would be much of an issue for sessions. Just put the persistent session storage model into its own database all by itself. Before you ever hit the wall, you'll probably need to partition the table to make selects and updates faster. Once you do hit the wall, you just need to find a way to get each partition into its own 'master' database, giving you ~14K writes per partition. At that point, you could scale it horizontally just like the apps. I only pretend to be a DBA, so I'm a little fuzzy on how to accomplish this last bit, but it doesn't sound unreasonable. I'd do the partitioning criteria in the app. Derive it from session data and determine the database to use from that. > I would think you would have a far greater challenge scaling the rest of your database this way. Sessions are easy, because there is a single table with no relationships to anything. Partition based on session id and you should get a fairly even distribution. I would imagine the real problem for "Large" apps is going to be the rest of that RDBMS. If your app is write heavy and your data structure is spread out in lots of little tables, then partitioning everything correctly sounds much more challenging. Agreed. Maik _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Ember ERRest integration
by Michael Kondratov 29 Apr '13

29 Apr '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Ember ERRest integration
by Kieran Kelleher 29 Apr '13

29 Apr '13

Just have a look at the static initialization block at the top of ERXRestFormat class. Look at the SproutCore as an example and the classes involved in the registration of the SproutCore format and how they are implemented. On Apr 27, 2013, at 5:37 PM, Michael Kondratov <michael(a)aspireauctions.com> wrote: > I am working on integrating Emberjs RestAdapter with ERRest. So far I wrote an EmberFormatter and a simple relationship fetcher. Having difficulties with RestReader and side loaded relationships. Ember sends objects in a slightly different format. > > Anyone working on something similar? Any tips? > > Michael Kondratov > 216-544-8938 > Kondratov Labs LLC _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com > > This email sent to kelleherk(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: EOF related objects present a lot in the heap
by Ramsey Gurley 29 Apr '13

29 Apr '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: EOF related objects present a lot in the heap
by Ramsey Gurley 29 Apr '13

29 Apr '13

On Apr 29, 2013, at 2:13 AM, Musall Maik wrote: > re-post as I forgot to post to the list > > Am 26.04.2013 um 21:12 schrieb Ramsey Gurley <rgurley(a)smarthealth.com>: > >> Advantages of persistent sessions: >> >> * Frees memory at the end of the RR loop >> * Easier to manage deployments. Sessions are distributed across instances. >> * Sessions can last as long as you want. >> >> Disadvantages of persistent sessions: >> >> * Hard. Everything must be serializable on your session. Your EOs, your WOComponents, everything. Fixing serialization errors is no walk in the park. >> * Serialization adds a few milliseconds wait to the RR loop. >> * Database load. Every RR loop is two selects and an update on a session row. Even if you isolate the session in their own database, there's a wall there. Get large enough and you'll hit it. Postgres 9.2 can handle about 14,000 writes per second according to what I've read. > > Do you think it would be possible to not serialize out the session on each RR loop, but instead having a short timeout delay (like 10 or 30 seconds), make the session persistent once the timeout is reached, and keeping the actively used sessions in memory? > > Could that be "best of both worlds"? :-) Of course you wouldn't spare the serialization debugging. > > Maik If you retain sessions in memory, even for a little while, you lose the second advantage: session distribution. That is just as important to me as the memory savings because it allows for horizontal scaling across commodity machines. Applications under heavy load? Just add more instances. You'll never hit the wall on the apps. Only on the database. Even with the database, I doubt it would be much of an issue for sessions. Just put the persistent session storage model into its own database all by itself. Before you ever hit the wall, you'll probably need to partition the table to make selects and updates faster. Once you do hit the wall, you just need to find a way to get each partition into its own 'master' database, giving you ~14K writes per partition. At that point, you could scale it horizontally just like the apps. I only pretend to be a DBA, so I'm a little fuzzy on how to accomplish this last bit, but it doesn't sound unreasonable. I would think you would have a far greater challenge scaling the rest of your database this way. Sessions are easy, because there is a single table with no relationships to anything. Partition based on session id and you should get a fairly even distribution. I would imagine the real problem for "Large" apps is going to be the rest of that RDBMS. If your app is write heavy and your data structure is spread out in lots of little tables, then partitioning everything correctly sounds much more challenging. Ramsey _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0