[igarashitm]

Thank you for your response! I see, Tim. I also have attached to JIRA.

https://jira.jboss.org/jira/browse/HORNETQ-189

My prototype already have realized two things, OutgoingTweetsHandler consumes from a queue and forwards to twitter, and
IncomingTweetsHandler consumes from twitter and forwards to a queue. Is the direction of this implementation correct?

[timfox]

Hi Tomohisa-

I had a quick look at your prototype, it looks like a good first attempt.

Clebert will look at it in more detail next week, here are a few initial observations:

1) Incoming tweets handler -currently the run() method enters a long running loop. We can't really do it this way since it will prevent the thread being used elsewhere in the server. If you need to poll twitter you can use the scheduled executor this. Streaming would be preferable though.

Also when you send the received twitter as a message, you don't need to create a session, producer etc - you can send it directly to the postoffice - see how it is done in ServerSessionImpl.send() - this will simplify the code.

2) The outgoing handler looks reasonable - although the run() method just seems to be setting up the objects and returning immediately - therefore there's no need for it to be called by an executor when starting up.

[igarashitm]

Hello Tim,

Thank you for your advice!

I've fixed those points and attached the new file.

https://jira.jboss.org/jira/secure/attachment/12334245/hornetq-189-twitter-support-prototype-20100509.svndiff

changes:

* IncomingTweetsHandler sends message directly to the PostOffice
* IncomingTweetsHandler#run() is now executed by  ScheduledExecutorService#scheduleWithFixedDelay() for polling
* OutgoingTweetsHandler implements org.hornetq.core.server.Consumer

* Add Twitter4j dependency into pom.xml

And I'll write the test code for next step.

----

Thanks

igarashitm

[timfox]

igarashitm,

Thanks, this looks good, I think you're almost there

We're currently in the process of getting 2.1 out. But we can start to integrate your work into TRUNK, probably next week.

[igarashitm]

Hello Tim,

Thanks to your review.

I've added some fixes, some integration test cases and an example for twitter-connector. I tried to attach the patch to JIRA but couldn't, so attach to here now. I'll also attach to JIRA later.

(2010/05/18) attached to JIRA.

https://jira.jboss.org/secure/attachment/12334403/hornetq-189-twitter-support-20100516.svndiff

Thanks

igarashitm

[igarashitm]

Hello all,

Now I trying to deal with the feedback from Andy(Thanks Andy ),

https://jira.jboss.org/browse/HORNETQ-189

We should discuss about the point 7,

7. The example and test use the titter hornetq account i guess u created. The tests may not work on hudson because of firewall restrictions and i am not sure whether having a public account is a good idea. Is there any way to use a fake twitter URL that we can fake. Might be best to raise this issue on the dev forums and w can all discuss it.

There are 2 ways to solve this:

1. connect to fake URL as Andy said. maybe create simple TCP server on the testcase and connect to it
2. use HTTP proxy and connect to real twitter URL
   1. set system property "twitter4j.http.proxyHost=<proxy_hostname> twitter4j.http.proxyPort=<proxy_port_number>"

I think 1 is reasonable for testcase, but 2 is better for example. User trying to do the example may want to know real behavior.

Could you give me any advice ?

----

Thanks,

igarashitm

[timfox]

Guys, do you know there's an actual problem with twitter on Hudson?

I wouldn't force yourselves to jump through hoops unless you know this is the case.

[ataylor]

Tim Fox wrote:

Guys, do you know there's an actual problem with twitter on Hudson?

I wouldn't force yourselves to jump through hoops unless you know this is the case.

Thats fine if it works on Hudson, I just asked igarashitm to post about it to make sure everybody is ok having a public twitter account. Anyone could run a DOS just by tweaking our code.

[igarashitm]

Examples are also executed by Hudson?

If so, I should use fake Twitter URL on both testcase and examples, and real twitter account will not be needed any more.

[clebert.suconic]

I think we shouldn't have any twitter user/password as part of our source tree. The account will probably be blocked a spammer as as soon as spammers get access to the public account.

I would use system varaibles on tests and examples.

We could set the user/password on hudson scripts. and users could provide the system variables as part of their runs.

something like

set TWITTER_ACCOUNT=clebert

set TWITTER_PASSWORD=<password>

./run.sh

And the same on hudson.

[ataylor]

Clebert Suconic wrote:

I think we shouldn't have any twitter user/password as part of our source tree. The account will probably be blocked a spammer as as soon as spammers get access to the public account.

I would use system varaibles on tests and examples.

We could set the user/password on hudson scripts. and users could provide the system variables as part of their runs.

something like

set TWITTER_ACCOUNT=clebert

set TWITTER_PASSWORD=<password>

./run.sh

And the same on hudson.

+1