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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by ovidiu.feodorov＠jboss.com

I spend a good part of the day today analyzing http://jira.jboss.com/jira/browse/JBMESSAGING-721 and its implications (which include http://jira.jboss.org/jira/browse/JBMESSAGING-410 and http://jira.jboss.org/jira/browse/JBMESSAGING-520) On one hand, the fixes for JBMESSAGING-410 and JBMESSAGING-520 insure that a JMS session created using a JMS connection produced by the JCA connection factory behaves as NON-TRANSACTED in absence of a global JTA transaction. This is an intuitive behavior, users rely on it, JBossMQ behaves similarly, and reportedly, other JMS providers as well. Unfortunately, the fix caused http://jira.jboss.com/jira/browse/JBMESSAGING-721. Reverting it would fix MDB redelivery problem, but it will break JBMESSAGING-410 and JBMESSAGING-520 again. At this moment, I am tempted to blame JCA and say that the fix for JBMESSAGING-410 and JBMESSAGING-520 belongs to the JCA layer. However, users don't see JCA, they see JBoss Messaging not working as expected. I haven't reached a definitive conclusion yet, I will continue thinking about this issue tomorrow. In the mean time, the fix for http://jira.jboss.org/jira/browse/JBMESSAGING-748 is badly needed at some production sites, so I will release a partial service pack (1.0.1.SP3) but not make it available for public consumption, pending a resolution on JBMESSAGING-721, which will be incorporated in 1.0.1.SP4. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003163#4003163 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003163

19 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Exception propagation using HTTP servlet transport on 1.

by tom.elrod＠jboss.com

Just ran the org.jboss.test.remoting.transport.servlet.ServletInvokerTestClient test (which extends org.jboss.test.remoting.transport.web.WebInvokerTestClient) with latest JBossAS 4.2.0 code base and remoting code base (see src/test/org/jboss/test/remoting/transport/servlet/readme.txt for instructions how to setup test). The code within WebInvokerTestClient that tests exception handling looks like: | Object response = null; | try | { | response = remotingClient.invoke(WebInvocationHandler.THROW_EXCEPTION_PARAM, metadata); | assertTrue("Should have thrown WebServerError and not made it to here.", false); | } | catch (IOException error) | { | // having to check class name instead of just catching type WebServerError so | // can use for backwards compatibility tests since WebServerError is new since 2.0.0.CR1. | if (error.getClass().getName().endsWith("WebServerError")) | { | assertTrue(true); | } | else | { | assertTrue("Did not get WebServerError thrown as expected", false); | } | } | metadata.put(HTTPMetadataConstants.NO_THROW_ON_ERROR, "true"); | response = remotingClient.invoke(WebInvocationHandler.THROW_EXCEPTION_PARAM, metadata); | if (response instanceof Exception) | { | System.out.println("Return from invocation is of type Exception as expected."); | assertTrue("Received exception return as expected.", true); | } | else | { | System.out.println("Did not get Exception type returned as expected."); | assertTrue("Should have received Exception as return.", false); | } | This test passes when running with the servlet invoker. In the case of servlet invoker, org.jboss.remoting.transport.http.WebServerError is thrown (or returned for the second invocation), so the original exception thrown on the server side is not the one thrown on the client side. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003122#4003122 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003122

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message bridge committed

by ovidiu.feodorov＠jboss.com

Fantastic! This is a nice chunk of work ... We're getting closer to code completeness for 1.2. For all who are interested, we're very well positioned to reach our Feb target. We might even deliver 1.2.GA sooner. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003090#4003090 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003090

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Can't deploy processdefinition from GPD into jBPM 3.2 -

by jeffdelong

Hum, changing the TransactionFactory from CMT to JTA did not solve the problem, but setting isCurrentSessionEnabled to false in jbpm.cfg.xml did !!!!! Tom, you probably want to check with the Hibernate guys on this; my understanding is that if you invoked getCurrentSession and there was none, hibernate would create a session for you. Somehow if it is creating it, it is not creating a transaction along with it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003085#4003085 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003085

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message bridge committed

by timfox

Forgot to say: For QOS_ONCE_AND_ONLY_ONCE with source and destination having different resource managers, then both source and destination need to provide fully functioning XA resource implementations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003076#4003076 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003076

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Message bridge committed

by timfox

The new message bridge has been committed in TRUNK. http://jira.jboss.com/jira/browse/JBMESSAGING-264 The message bridge is a component which forwards messages from one destination to another. The source and target destinations can be one the same server or on different remote servers. The bridge should work with any JMS 1.1 compliant JMS server, although has only been tested with JBM. The bridge comes as a non MBean class, and also has an MBean wrapper so can be deployed on the JBoss AS JMS spine. When using the bridge you specify a desired quality of service, this can be one of: QOS_AT_MOST_ONCE With this QoS mode messages will reach the destination from the source at most once. The messages are consumed from the source and acknowledged before sending to the destination. Therefore there is a possibility that if failure occurs between removing them from the source and them arriving at the destination they could be lost. Hence delivery will occur at most once. This mode is avilable for both persistent and non persistent messages. QOS_DUPLICATES_OK With this QoS mode, the messages are consumed from the source and then acknowledged after they have been successfully sent to the destination. Therefore there is a possibility that if failure occurs after sending to the destination but before acknowledging them, they could be sent again when the system recovers. I.e. the destination might receive duplicates after a failure. This mode is available for both persistent and non persistent messages. QOS_ONCE_AND_ONLY_ONCE This QoS mode ensures messages will reach the destination from the source once and only once. (Sometimes this mode is known as "exactly once"). If both the source and the destination are on the same JBoss Messaging server instance (same resource manager) then this can be achieved by simply sending and acknowledging the messages in the same local transaction. The bridge will automatically detect this and use a local tx as appropriate. If the source and destination are on different servers (different resource managers) this is achieved by enlisting the sending and consuming sessions in a JTA transaction. The JTA transaction is controlled by JBoss Transactions JTA implementation thus providing a very high degree of durability. If JTA is required then both supplied connection factories need to be XAConnectionFactory implementations. This mode is only available for persistent messages. This is likely to be the slowest mode since it requires extra persistence for the transaction logging. One thing to note: For a specific application it may possible to provide once and only once semantics without using the QOS_ONCE_AND_ONLY_ONCE QoS level. This can be done by using the QOS_DUPLICATES_OK mode and then checking for duplicates at the destination and discarding them. Some JMS servers provide automatic duplicate message detection functionality, or this may be possible to implement on the application level by maintaining a cache of received message ids on disk and comparing received messages to them. The cache would only be valid for a certain period of time so this approach is not as watertight as using QOS_ONCE_AND_ONLY_ONCE but may be a good choice depending on your specific application but it less general than using JTA. Other stuff: The bridge can be started and stopped, or temporarily paused and resumed. A maximum message batch size can be specified for the bridge, the bridge will then consume and forward messags in batches of this size. This is likely to be more performant then consuming / sending one by one. A maximum batch time can also be configured. If so, then if less than maxBatchSize messages have been consumed then the batch will be sent if the maxBatchTime is exceeded. This allows messages to be sent sooner if there are long delays between messages. The bridge can consume from a queue, or a durable or non durable subscription, and a forward to a queue or a topic. A JMS selector can be specified for the bridge so it will only forward messages that match the selector criteria. If the connection to the source or target destination is lost, then the bridge can be configured to retry at configurable intervals, and a configurable number of times. This allows it to be more resilient to temporary network loss, especially useful for forwarding from one LAN to another across a brittle WAN. There is a minor issue to resolve with transaction recovery but this is all pretty much done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003072#4003072 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003072

19 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Plan to improve CMS integration

by julien＠jboss.com

I have modularized management integration into core as well. Thomas can you check it ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003061#4003061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003061

19 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-615 still present in Embedded-ALPHA9

by jazir1979

oh, i see!! thanks for the info.. "bill.burke(a)jboss.com" wrote : We've totally scrapped Embedded EJB3 and started the Embedded JBoss project based on JBoss 5 kernel. New Embedded JBoss will be full featured. Most features of regular jboss should be available in embedded. | | If you want to testdrive, checkout head SVN. its in the jboss-head/embedded directory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003045#4003045 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003045

19 years, 2 months

1
0
0 / 0

[Design of JBossCache] - markNodeCurrentlyInUse() - race condition

by genman

It seems to me that Region#markNodeCurrentlyInUse() does not really do what it is supposed to do. Basically, it adds an event to the queue. And what can happen is that 4 seconds later (say, if event queue processing is every 4 seconds), is that the node can disappear after this method is called. Doesn't this make this method fairly useless? Shouldn't there just be a method on a Node to prevent eviction? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003044#4003044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003044

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Soap with Attachments and document/literal

by darran.lofthouse＠jboss.com

Here is the correct extract: - <schema targetNamespace='http://www.jboss.org/support/photoalbum/types' | xmlns='http://www.w3.org/2001/XMLSchema' | xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' | xmlns:tns='http://www.jboss.org/support/photoalbum/types' | xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' | xmlns:ref='http://ws-i.org/profiles/basic/1.1/xsd'> | <complexType name='Photo'> | <sequence> | <element name='caption' nillable='true' type='string'/> | <element name='image' type='ref:swaRef'/> | </sequence> | </complexType> | <element name='publishPhoto' type='tns:Photo'/> | <element name='publishPhotoResponse' type='int'/> | </schema> | </types> | | <message name='AlbumEndpoint_publishPhoto'> | <part element='ns1:publishPhoto' name='publishPhoto'/> | <part name='mimepart' type='xsd:hexBinary'/> | </message> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003040#4003040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003040

19 years, 2 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 January 2007