search

CMPUT301W16T15 / Shareo

Group Project Android App
MIT License
3 stars 0 forks source link

Connection issues in ModelTest #13

Closed asampley closed 8 years ago

asampley commented 8 years ago

Like the title. If you run ModelTest, you may see what I mean. I get: java.lang.IllegalStateException: Connection is still allocated It varies where it is, it may have to due with some concurrency issues in useMainThread somewhere. I have been staring at it for too long, so if anybody else finds the problem, that would be a welcome relief.

Bradshawz commented 8 years ago

Haven't looked at it, but I can tell you it's because multithreaded code is hitting a static class, where the httpclient can't keep alive more than one network call at a time. On Mar 22, 2016 1:16 PM, "Alex Sampley" notifications@github.com wrote:

Like the title. If you run ModelTest, you may see what I mean. I get: java.lang.IllegalStateException: Connection is still allocated It varies where it is, it may have to due with some concurrency issues in useMainThread somewhere. I have been staring at it for too long, so if anybody else finds the problem, that would be a welcome relief.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/CMPUT301W16T15/Shareo/issues/13

Bradshawz commented 8 years ago

For general purposes use of the app, you only need to delete Things and Bids. And arguably, you should only be able to delete a thing if it doesn't have any bids on it and isn't loaned out. Therefore, an object only worries about deleting itself in an asynchronous fashion.

Main reason the test is crashing and burning is because even if a deleter is originally run synchronously, the children it deletes seem to be being called asynchronously. You wont need to chain the asynchronous calls together (for the reason stated in the first paragraph). Because of this, it should be easier to make the synchronous deleters you want for testing.

asampley commented 8 years ago

See, I figured it was something along those lines, but I couldn't figure out exactly where. I would however argue that you may want to delete an item despite there being bids placed on it. Let's say some people bid on a game I own, but then I decide I don't want to lend it anymore. Do I have to delete all the bids other people placed? Should I be allowed to delete other people's bids? I would say that I should be able to just delete the game itself.

Bradshawz commented 8 years ago

If the app actually required real user experience, you would close the bidding period and then delete the game. Also you wouldn't delete the bids, you would modify their state to be denied so the people who made the bid would be notified that bids they previously made were denied so they don't have bids disappearing on them.

However, these arn't required use cases so there's no need to implement them. (Until notified otherwise)

Also another note in the deleters, they make internal calls on transient fields. There is no guarentee transient fields will not be null. This will also cause the tests to fail. Always use the getters on transient fields, no exceptions.

asampley commented 8 years ago

Yes, I noticed that. A bit sloppy on my part, but that is what testing is for, and I am currently fixing it.

Bradshawz commented 8 years ago

I can fix the java.lang.IllegalStateException: Connection is still allocated by forcing jobs to only run one at a time. Currently i'm not, so people realize when they are running multithreaded code when they think its synchronous. So don't worry about functions that could run two jobs at the same time. (This is more relevant for actual app use than tests, as tests will still fail when running async)