[JBoss Messaging] - NoLocal Subscription building up messages in server queue le
by engluer
I have a client that connects to the server with a publisher and subscriber on the same topic. The publisher publishes 1 KB message as fast as he can. The subscriber is setup as follows:
| subscriber =subscriberSession.createSubscriber(topic, null, true);
| subscriber.setMessageListener(new MessageListener(){
| public void onMessage(Message message) {
| messagesReceived++;
| }
| };
|
The number of messages received stays at zero BUT the number of messages on the server waiting to be delivered steadily increases, to the point that I run out of heap space. It would seem that it is correctly ignoring the messages on the client but that the client or server is not acknowledging the message so the messages stay in the queue on the server.
The messages are being sent as Non_perstistent on Jboss Messaging 1.4.0 GA with remoting 2.2.2 GA on JBoss 4.2.1
If I set:
| subscriberSession.createSubscriber(topic, null, false);
|
I correctly receive the messages and the number of messages waiting to be delivered on the server remains at 0.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093148#4093148
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093148
18Â years, 7Â months
[JBoss Seam] - s:fileUpload doesn't preserve pending value after immediate
by tynor
Seam 2.0.0.CR1
I have a form containing several h:inputText's, a s:fileUpload and an h:commandButton that is used to add an item to a server-side Set, which is then used to draw a dataTable on the facelet. (I'm in a manually flushed transaction:
| @Begin(flushMode=FlushModeType.MANUAL, join=true)
|
I use this sort of button on several forms without any trouble, but I'm having problems when there is an s:fileUpload control on the form -- when the button action fires and the screen refreshes, all the other controls (select boxes, text inputs, etc.) preserve their as-yet-unpersisted values, but the filename selected by the file upload control is cleared.
Is this a bug in s:fileUpload? Can I workaround somehow?
| <s:decorate id="txtDecoration" template="/WEB-INF/facelets/templates/edit.xhtml">
| <ui:define name="label">Text</ui:define>
| <h:inputText id="txt" value="#{myHome.instance.txt}"/>
| </s:decorate>
| <s:decorate id="fileDecoration" template="/WEB-INF/facelets/templates/edit.xhtml">
| <ui:define name="label">File</ui:define>
| <s:fileUpload id="file" data="#{myHome.data}" required="true"
| contentType="#{myHome.contentType}"
| fileName="#{myHome.fileName}" accept="application/pdf" />
| </s:decorate>
| <s:decorate id="addDecoration" template="/WEB-INF/facelets/templates/edit.xhtml">
| <h:commandButton id="add" value="Add" immediate="true"
| action="#{myHome.addItem}"/>
| </s:decorate>
| ...
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093146#4093146
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093146
18Â years, 7Â months
[JBoss jBPM] - Re: Large
by joe_jbossï¼ freemansoft.com
I can reply to this.
The project has 50+ process definitions located in a hierarchical fashion where the packaging structure generally matches the process-to-subprocess hierarchy. The top level process definition sits at the top and the other process definitions sit underneath it, probably 5 or 6 deep. It takes 5 minutes open processDefinition.xml from the top level in Eclipse using jbpm-jpdl-designer.3.1.0.
The first directory structure shows our "problem" layout. If you move defs.processDefinition.xml into a subdirectory than it opens instantly. So the secnd directory structure works fine.
example poorly performing number
defs
defs.processDefinition.xml
defs.sub1
defs.sub1.processDefinition.xml
defs.sub2
defs.sub2.processDefinitions.xml
defs.sub2.sub3
defs.sub2.sub3.processDefinition.xml
defs.sub2.sub3.sub4
defs.sub2.sub3.sub4.processDefinition.xml
defs.sub2.sub3.sub5
defs.sub2.sub3.sub5.processDefinition.xml
defs.sub2.sub3.sub6
defs.sub2.sub3.sub6.processDefinition.xml
--45+ other entries follow--
Example well performing structure
defs
defs.master
defs.master.processDefinition.xml
defs.sub1
defs.sub1.processDefinition.xml
defs.sub2
defs.sub2.processDefinitions.xml
defs.sub2.sub3
defs.sub2.sub3.processDefinition.xml
defs.sub2.sub3.sub4
defs.sub2.sub3.sub4.processDefinition.xml
defs.sub2.sub3.sub5
defs.sub2.sub3.sub5.processDefinition.xml
defs.sub2.sub3.sub6
defs.sub2.sub3.sub6.processDefinition.xml
--45+ other entries follow--
We're pretty convinced that there is a recursion problem. 2nd level process definitions with several children also have slightly slower performance but not as bad as the instance at the top.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093142#4093142
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093142
18Â years, 7Â months
[JBoss Messaging] - JBoss Messaging 1.4.0 noLocal subscriber fills topic causing
by maihde
In our application we have found that a simple Publisher/Subscriber that has noLocal set will eventually fill the topic with messages, and if the topic has no maximum size then a OutOfMemory Heap error will occur.
Our configuration isn't clustered and can be recreated using only a single publisher and subscriber connection. Basically after starting the publisher, I use the JMX console to monitor the message counter, which keeps increasing. If I don't invoke the removeAllMessages method or disconnect the client then the server eventually runs out of memory. If I attach other subscribers, their message counters stay at zero because they receive their message. It appears that the server doesn't receive an ACK for the ignored message. I'm going to look at the code to see if I can find anything.
Is it possible that this is a configuration problem on my server? Did the API for ignoring local messages change between JBoss MQ and JBoss Messaging (our identical code ran fine with JBoss MQ).
Thanks for your help.
~michael
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093140#4093140
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093140
18Â years, 7Â months