Asking for help again about my thread debug

As http://www.ruby-forum.com/topic/65495 has shown,I have drawn into
trouble about my thread debugging for some days,and need help to solve
it urgently!

This thread problem comes from the design requirements that my web
application will get the rss feeds read which are generated by the web
application itself.
Feedtools question - Rails - Ruby-Forum has shown my code,and the key code
is the following:

@feed =
FeedTools::Feed.open(“http://localhost:3000/feeds/userrss/#{params[:id]}”)

userrss is the controller to generate rss feeds:
class FeedsController < ApplicationController
def userrss
@user = User.find_by_id(params[:id])
@articles = @user.articles(:all,:order => ‘updated_at desc’)
@feed = FeedTools::Feed.new
@feed.title = “#{@user.login}”
@feed.author = “#{@user.login}”
@feed.link = “http://localhost:3000
@articles.each do|@article|
@feed_item = FeedTools::FeedItem.new
@feed_item.link =
http://localhost:3000/articles/view/#{@article.id}
@feed_item.content = “#{@article.body}”
@feed.entries << @feed_item
end
end
end

The above code can not work because of the thread problem:a controller
will not return until it got the response from another controller.
When I use Webrick webserver,If I change the value of
@@allow_concurrency of Actionpack,it can work,but will not If I deploy
the web application using Apache+scgi. Currently my operating system is
windows,what should i do to conquer this thread question,i have no idea
but a silly scheme:

To use two web server on one computer with different http request
port,for example Apache of 80 and Webrick of 3000,and then deploy the
web application under both Apache and Webrick with:
@feed =
FeedTools::Feed.open(“http://localhost:3000/feeds/userrss/#{params[:id]}”)
which the request of http://localhost:3000/feeds/userrss/#{params[:id]}
will cause the Webrick to process it.

Very confused and urgent,Thanks!!!

Charlie

charlie wrote:

As Thread question - Rails - Ruby-Forum has shown,I have drawn into
trouble about my thread debugging for some days,and need help to solve
it urgently!

This thread problem comes from the design requirements that my web
application will get the rss feeds read which are generated by the web
application itself.
Feedtools question - Rails - Ruby-Forum has shown my code,and the key code
is the following:
I didn’t follow your original problem thread, so I’m not sure if this
was suggested and ruled out. Why not cache the rss feed when you
generate it, and read the cached file rather than trying to connect back
into the app? That would avoid threading completely…

On May 13, 2006, at 9:07 AM, charlie wrote:

I just use the example of generating feeds of articles to explain the
thread problem more explicitly,in fact,the web application is more
complicated,and in many cases the feeds will be first accessed by the
web application itself,it has a compex logic–the design requires
that…

Alex Y. wrote:

Charlie-

To make this happen you need to get two rails backends running.

Since you’re on windows lighttpd/fcgi is not an option. But You can
run lighttpd/mongrel on windowsw. You set up lighttpd to proxy
requests to two mongrel servers running. This way you can do exactly
what you are trying to do.

But from looking at what you are trying to do i think you may be

approaching it from the wrong angle. Why do you need to make a http
requests to your own application? why not just make a way to get the
same data from within your app without making an http request? Give
me some more details and maybe I can help you come up with a better
way of doing this then the extra http requests. After all rails is an
integrated environment, and you should be able to find a way to do
what you want without the extr http request.

-Ezra

I just use the example of generating feeds of articles to explain the
thread problem more explicitly,in fact,the web application is more
complicated,and in many cases the feeds will be first accessed by the
web application itself,it has a compex logic–the design requires
that…

Alex Y. wrote:

charlie wrote:

As Thread question - Rails - Ruby-Forum has shown,I have drawn into
trouble about my thread debugging for some days,and need help to solve
it urgently!

This thread problem comes from the design requirements that my web
application will get the rss feeds read which are generated by the web
application itself.
Feedtools question - Rails - Ruby-Forum has shown my code,and the key code
is the following:
I didn’t follow your original problem thread, so I’m not sure if this
was suggested and ruled out. Why not cache the rss feed when you
generate it, and read the cached file rather than trying to connect back
into the app? That would avoid threading completely…

I wonder if it would help to write some stand-alone ruby script to
generate
the feeds, then have your userrss action run the script using command
expansion? And then when you read the feed you can have

@feed = FeedTools::Feed.open(RAILS_ROOT + ‘/whatever/feed-generator.rb’)

Instead of

@feed =
FeedTools::Feed.open(“http://localhost:3000/feeds/userrss/#{params[:id]}”)

If you go this route, be sure to add “require ‘config/environment’” to
your
standalone script so you can access your models.

I agree that it seems like you shouldn’t have to make an extra HTTP
request.
I tried googling “command line rails” to see if there were any way to
interact with controllers from the command line, but I didn’t find
anything.
I’m sure there’s a way to do it though.

On May 13, 2006, at 9:30 PM, charlie wrote:

to say,inside the web application,there is an rss reader to read feeds
both from inside and outside. The feeds from inside are for the
friends’
published information, and I think this kind of style can give a good
experience for users.

Charlie-

Maybe you should consider caching the users rss feeds to disk using

caches_page. Then use an observer to expire and rebuild the cache
when one of the rss feeds gets updated. This way you could just read
the other users rss feeds from within your app just by reading it off
disk with render :file => ‘/other/users/feed.xml’.

For external websites a you can still use http even with only one

webrick or mongrel or whatever process running your rails app. And it
wouldn’t block when you need to show users other rss feeds from
within your app.

Cheers-
-Ezra

Hi,Ezra
Let me explain some details about my web application.
In my web app,users can register and publish their information such as
books to be sold,dvd,…
These information can be generated as rss feeds and read by any others.
Another characteristic special is that the users registered can have
friends that are also registered users.There is a panel to read their
friends’ rss information together with other foreign rss feeds-- that is
to say,inside the web application,there is an rss reader to read feeds
both from inside and outside. The feeds from inside are for the friends’
published information, and I think this kind of style can give a good
experience for users.

Ezra Z. wrote:

But from looking at what you are trying to do i think you may be
approaching it from the wrong angle. Why do you need to make a http
requests to your own application? why not just make a way to get the
same data from within your app without making an http request? Give
me some more details and maybe I can help you come up with a better
way of doing this then the extra http requests. After all rails is an
integrated environment, and you should be able to find a way to do
what you want without the extr http request.

-Ezra