I’ve confirmed that this is an issue related to the size of the data being returned via the xml-rpc call. But I have no idea what to do with that information.
If you’re groups get a long winded topic going … you’ll see it too!
How long winded do I have to be before it fails? Gonna go look at the issue but need some idea of text len that kills it.
As usual it’s confusing as to *where* you are posting the text. If you do this, ‘big chunk of text’ as reply repeatedly from the bp group forums side, *what* happens? The bp side is where the failure is?
Not sure if this is helpful at all?
http://osdir.com/ml/cms.opengroupware.xmlrpc.devel/2006-10/msg00007.html
I’ll see if I can find anything more…
Hmm. I see what you are saying though. Perhaps it does have something to do with the xmlrpc comm stuff. The underlying bbpress_live code gets a topic and all the replies in one gulp. Doesn\\\’t matter if there is 1 reply or 100. It gets them all.
Put\\\’s me on the right track. OK. Off to investigate.
Well, maybe I remember incorrectly. There does seem to be pagination code in there.
There’s pagination code in there but bbpress ignores the pagination parameters. We get the topic and all replies. That’s what I remember. It’s coming back to me now. Still looking.
Burt: Something to note too… This could be the same way the bbGroups plugin works and the way it pulls all user data? Similar issue we ran into before? Mayhaps?
My guess is that the xmlrpc memory limit is set on the server and probably needs to be overridden in .htaccess. If I was going to guess, which I’m not… 
Hmm. Ya, you might be right. xmlrpc may have an inherent limit on the size of the returned data in xml. Wow. That *might* have been the problem you were running into also. I don’t think it’s a memory limit thing for the server. It might be related to the IXR server that does the grunt work.
Good call John.
The text is posted on the buddypress interface for a topic. The number of replies isn’t important, it’s the amount of characters contained in all replies. From my testing, the limit seems to be around 80,000 characters (with spacing). That sounds like a lot but really isn’t in an active topic.
For example, here’s a link to the problem – http://brentandmary.net/groups/usma-87/forum/topic/9
Here’s that same “topic” via the bbpress backend – http://brentandmary.net/forums/topic.php?id=9
To reproduce
- Have a buddypress install with bbpress integrated
- From buddypress, go into a group
- Create a new group topic
- Copy 80,000 or so characters into the topic
You’ll eventually get to a point where buddypress returns a message “There are no posts for this topic.”
Yesterday, I looked at that post about “LSMaxSearchCount” but I don’t see anywhere that’s configured nor where to configure it. Seems like a likely culprit.
\”Copy 80,000 or so characters into the topic\” 
I don\’t know why I find those directions amusing but I do. Anyway. What is the LSMaxSearchCount post you are talking about. That doesn\’t even seem to be in the forums here. Did a search. That doesn\’t even seem to be a likely bp, mu or bbpress var. They don\’t use camel case. Can you point me to that post please?
I do see this happening on your site. I have to make sure I’m looking at the right xmlrpc code on the bbpress side. There are two ‘get the topic’ functions. I have to check and make sure I track things from beginning to end. Don’t want to be looking at code that isn’t being used on the bbpress xmlrpc side.
Gimme a few.
What is the LSMaxSearchCount post you are talking about
From John’s post earlier in this thread:
http://osdir.com/ml/cms.opengroupware.xmlrpc.devel/2006-10/msg00007.html
Ok. Thanks. We are posting around each other here and I missed that post of his.
What does the error log say about this? Anything? I found that right before the xmlrpc server sends the data it does strlen() on what it\\\’s gonna send. Then it sends it as one giant string. Over 64K and what happens? Looking to see if there is an inherent limit on string lengths.
I see what that LM… thread is about. As far as I can tell, xmlrpc in bbpress isn\’t limiting the num of \’things\’ returned. However it returns all the \’things\’ in one big string. It builds up the entire xml response and sends it.
I have a string that is 455K in Size. I tried creating an XML Node
with this string as it’s value, but the string always gets cut off at
about 83K –
From: http://bugs.php.net/bug.php?id=46987
LOL … I just found the exact same thing. The 83K really jumped out at me.
Well, if that does apply, that’s a problem!
Great minds. Workaround is the obvious. If it hurts when you do that, don’t do that.
Maybe there’s a way to just issue a warning or close the topic automatically before it reaches the magic limit. Whatever that is, for whatever reason it exists.
Start a new topic please.
yeah, that’s not a very user friendly solution. I’d have to ponder how to even do that!
Seems like a simpler solution is to just call the data directly. The bbpress tables are integrated into the same database. The same user table is being used. Why not just directly query the bb_ tables instead of xmlrpc?
Not everyone is using ‘deep integration’. There’s other wonderful whackyness involved in that. Don’t think you are using that are you? Anyway group forums is built on the xmlrpc comm for talking to bbpress. It’s what we got that works in all installs.
If by “deep integration” you mean loading wordpress at the top of bb-config.php, no, we don’t do that. But, if the tables share the same database, that’s not needed.
If the xmlrpc method WILL break when retrieving large topics, then I don’t see a choice but to directly query the bb tables. Otherwise, using bbpress for the group topics is fatally flawed.
Andy and Burt,
Thank you very much! The file you sent me yesterday did fix the problem with my large thread. I’d set pagination to occur at 50 posts. Once I reduced that to 40 posts, the topic started working again (http://buglenotes.com/groups/free-for-all/forum/topic/79)
One item to note, bp_the_topic_latest_post_excerpt() is still broken for large topics. See http://buglenotes.com/groups/free-for-all at the Obama Chronicles II topic.
https://trac.buddypress.org/ticket/628 fixes that issue for anyone interested.
