If you prepare a patch (diff against 3.2 or 4.0 CVS) you can either post it to
Sourceforge or e-mail it to me. I'd be happy to check and apply it.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3850030#3850030
Reply to the post :
http://www.jboss.org/index.
4.0 is not really consistent with 3.2 yet. Looks like a lot of 3.2 changes weren't
put in 4.0 but I am not sure what to do. The bug isn't in 4.0, probably because the
code hasn't been merged.
I fixed 3.2, so build off of CVS or wait for 3.2.6 release.
View the original post :
http://www.jbo
The best place to submit bugs is sourceforge.net/projects/jboss . I'll fix this and
see what I can do about 4.0. Thanks.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3849478#3849478
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting
In 1.7.2, you can add "-noexit" to the args you pass into DatabaseManager.main() and
it won't quit...
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3848865#3848865
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3848865
This is not a developer question, so please don't post to this forum.
I'll add this answer to the Wiki.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3841543#3841543
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=38415
I think rather than have a limit of the number of messages loaded, you should be able
to estimate the in-memory size of the messages and load to a memory limit. The size
should be calculated as the BLOBs are read in. This probably isn't much more trouble
than limiting the query by count.
For
A "cheap" way to improve performance would be to run the selector against messages
added to the queue, add references to these messages into a hashtable (key would be
the selector, value would be the sorted message IDs). When reading using a selector,
if it matches a pre-existing optimized sel
I want to take advantage of xdoclet's jboss.xmbean generation, however it is very
frustrating. Especially in 3.2.4 CVS.
Right now in 3.2.3, I have to do this to get the ServiceMBeanSupport methods to show
up:
Overall looks very helpful.
I wonder if it might make sense to have the different IL threads belong to different
thread groups, as the number of threads may be quite a lot. The JMX operation to
display these could then display and order them by group.
View the original post :
http://www.jbos
Unfortunately, there are some headers that are updated on the server, which means that
the serialized format for a SpyMessage becomes soon invalid.
Therefore, headers and the message body should be serialized as separate objects and
never combined as a single object. This means required change
10 matches
Mail list logo
