May 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss internal QA (Test Suite)] - Re: Server-side Testsuite Logging

by dimitris＠jboss.org

FYI, for reading the free memory on the server there is the jboss.system:type=ServerInfo mbean. For the total heap space, it has the following attributes: FreeMemory (total - used) TotalMemory (i.e. currently committed memory) MaxMemory (maximum) But there is also the listMemoryPools(true/false) operation to give you the same information displayed by JConsole. http://wiki.jboss.org/wiki/Wiki.jsp?page=HowCanIDisplayTheMemoryPoolUsage View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042787#4042787 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042787

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message expiration in JBossMQ - JBAS-4328

by wolfc

"timfox" wrote : You can't expect a general jms provider to fully honour JMSExpiration in all circumstances. Oi, I thought we were talking about a JBoss product here. :-) I would say either is does expiration or it doesn't, not a weird mixture were I don't expiration but others do. I understand that the expiration isn't real time, so there is always some slack between expiration and consumation of the message. "JMS 8.2.7" wrote : The JMS provider retains control of its messages until they are delivered to the MessageListener. This insures it is under direct control of message acknowledgment. Given the above JMS should provide full service to the message until it has passed through the message listener. BTW, does persistence work when the message has passed the consumer, but not the listener? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042774#4042774 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042774

18 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Do you have a plan that supports XPDL?

by kukeltje

some experiments are going on in the 'process virtual machine' code that is in CVS under the 'lightning' project View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042748#4042748 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042748

18 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jbpm as enterprise application

by mignag

Bom dia Ricardo Pelo nome suponho que percebas portugues. Desculpa esta forma de contacto mas as minhas expectativas sobre o JBPM estão a descer tanto que precisava de trocar algumas ideias não tão técnicas sobre isto - em português mesmo... Se puderes entra em contacto e mais uma vez peço desculpa por esta forma "abusiva" de utilização deste forum Miguel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042741#4042741 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042741

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Message expiration infinite loop

by clebert.suconic＠jboss.com

I guess the subject of the day is expiration.. what a coincidence! :-) This is a discussion about http://jira.jboss.org/jira/browse/JBMESSAGING-951 On my local copy, I have added a tracing at ServerSessionEndpoint that I don't want to commit but it was useful understanding this issue: | void expireDelivery(Delivery del, Queue expiryQueue) throws Throwable | { | ... | log.info("ExpireDelivery " + del + " queue = " + expiryQueue, new Exception()); | ... | } | Analyzing the logs, when running ExpiredMessageTest::testExpirationTransfer, I have a sequence of messages... This is the first one: | java.lang.Exception | at org.jboss.jms.server.endpoint.ServerSessionEndpoint.expireDelivery(ServerSessionEndpoint.java:720) | at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:207) | at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.java:120) | at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:612) | at org.jboss.messaging.core.ChannelSupport.handleInternal(ChannelSupport.java:759) | at org.jboss.messaging.core.ChannelSupport.handle(ChannelSupport.java:157) | at org.jboss.messaging.core.local.PagingFilteredQueue.handle(PagingFilteredQueue.java:114) | at org.jboss.messaging.core.plugin.postoffice.DefaultPostOffice.route(DefaultPostOffice.java:333) | at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:685) | at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:298) | at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:80) | at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java) | at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:152) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | And after that... it keeps in a infinite loop between these methods... | at org.jboss.jms.server.endpoint.ServerSessionEndpoint.expireDelivery(ServerSessionEndpoint.java:720) | at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:207) | at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.java:120) | at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:612) | at org.jboss.messaging.core.ChannelSupport$InMemoryCallback.afterCommit(ChannelSupport.java:1035) | at org.jboss.messaging.core.tx.Transaction.commit(Transaction.java:228) | at org.jboss.jms.server.endpoint.ServerSessionEndpoint.moveInTransaction(ServerSessionEndpoint.java:1069) | at org.jboss.jms.server.endpoint.ServerSessionEndpoint.expireDelivery(ServerSessionEndpoint.java:729) | at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:207) | at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.java:120) | at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:612) | at org.jboss.messaging.core.ChannelSupport$InMemoryCallback.afterCommit(ChannelSupport.java:1035) | at org.jboss.messaging.core.tx.Transaction.commit(Transaction.java:228) | at org.jboss.jms.server.endpoint.ServerSessionEndpoint.moveInTransaction(ServerSessionEndpoint.java:1069) | at org.jboss.jms.server.endpoint.ServerSessionEndpoint.expireDelivery(ServerSessionEndpoint.java:729) | at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:207) | at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.java:120) | at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:612) | at org.jboss.messaging.core.ChannelSupport$InMemoryCallback.afterCommit(ChannelSupport.java:1035) | at org.jboss.messaging.core.tx.Transaction.commit(Transaction.java:228) | So... after the message is expired.. .it is transfered to the ExpiryQueue.. and as it is expired it is transfered from the ExpiryQueue again to the ExpiryQueue and keeps in loop on that... The fix is an easy fix probably. I will do it tomorrow first thing in the morning... (Unless Tim or Serge want to fix it before me as they are few hours ahead in Europe :-) ) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042696#4042696 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042696

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message expiration in JBossMQ - JBAS-4328

by clebert.suconic＠jboss.com

"clebert.suconic(a)jboss.com" wrote : From what I looked on the testcase you should be receiving three messages, as time to live is set to 1 second, the MessageListener is set on the ConnectionConsumer and there is no wait between the send and connection start. | | If you want that behavior on the testcase I guess you should wait some time before you start the connection. Just for the record.. I didn't realize the wait on the MessageListener when I wrote that.. duh :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042694#4042694 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042694

18 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Do you have a plan that supports XPDL?

by wkzk

Hi. I'm researching a workflow engine that supports XPDL. Do you have a plan that supports XPDL at this time? no plan even now? i hope it could be jbpm ver4.0..... could you guys give me the jbpm's current position? Thanks in advance. Shige View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042683#4042683 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042683

18 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: suspend-resume() Method with problems

by jeffdelong

First off, this should be asked on the user forum, as this forum is for discussing the design of jBPM, not how to use it. Secon, before you post, you should try to describe what you want to do in a clearer manner, and provide examples of the process definition and your rules. In particular, it is not clear how your rules would get invoked, in order to determine if the value was greater than 10. Finally there are example of jbpm / rules integration in the jBPM 3.2 examples directory. You should look at them if you have not already done so. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042667#4042667 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042667

18 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - suspend-resume() Method with problems

by javi0704

HiGuys , i tried to develop jbpm with some rules (drools). I use just start-state, task-node, (task with action-ActionHandler variables) and end-state. So my problem is: suppose a user give a value for one varable this will be controll by the drool For example variableName is "value" So the drool-rule condition controlls if value>10 then Condition is ok the process will continue, when not ok==>Drools(in Consequence) this Task-Node must wait, block or lock till the value variable is correct that means till value>10 I tried this with the Method: to block the Task-node processInstance.suspend() also processInstance.wait() and to unblock the Task-Node processInstance.resume() also processInstance.signal()but it doesn't work. please help me with this problem with kind regards View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042663#4042663 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042663

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message expiration in JBossMQ - JBAS-4328

by timfox

What's happening in this test is the messages are sent, then almost immediately they are received by the connection consumer (which lives on the client side) - at this point they are not expired. Later on the connection consumer passes the messages onto the message listener and a delay is introduced, but by this time the messages are already on the client so won't get expired since JBossMQ doesn't do an extra client side check. I haven't actually run this test against JBoss Messaging but we do an extra client side expiration check as well as a server side one. This is particularly important to us since we buffer messages on the client side, therefore I would expect this test to pass for JBM. However, having said all that, the JMS spec is pretty loose about JMSExpiration: anonymous wrote : | When GMT is later than an undelivered message?s expiration time, the | message should be destroyed. JMS does not define a notification of message | expiration. | Clients should not receive messages that have expired; however, JMS does not | guarantee that this will not happen. | Since there are no guarantees I would say the JBossMQ is sub-optimal but not incorrect and is fully spec compliant. You can't expect a general jms provider to fully honour JMSExpiration in all circumstances. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042650#4042650 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042650

18 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums May 2007