[JBoss JIRA] Updated: (JBMESSAGING-375) Grouping of messages with JMSXGroupId
by Jeff Mesnil (JIRA)
[ http://jira.jboss.com/jira/browse/JBMESSAGING-375?page=all ]
Jeff Mesnil updated JBMESSAGING-375:
------------------------------------
Attachment: patch-JBMESSAGING-375.txt
updated Stian's patch for JBoss Messaging 1.4.0 (based on r3190):
- base class is RoundRobinDistributor
- "grouping" round robin algorithm is done in GroupingRoundRobinDistributor
- associated tests are in GroupingRoundRobinDistributorTest
- put test code common to RRDTest and GroupingRRDTest into
SimpleReferenceableReceiver class
- added support to reset bound receiver by setting JMSXGroupSeq to 0
some caveats:
- GroupingRRD's algorithm is brittle and depends on a lot of internals from
RRD which should not be exposed
-> maybe grouping should be handled directly by RRD?
- GroupingRRD is not used by MessagingQueue (still using RRD)
> Grouping of messages with JMSXGroupId
> -------------------------------------
>
> Key: JBMESSAGING-375
> URL: http://jira.jboss.com/jira/browse/JBMESSAGING-375
> Project: JBoss Messaging
> Issue Type: Feature Request
> Reporter: Tim Fox
> Assigned To: Tim Fox
> Fix For: 2.0.0 Beta 1
>
> Attachments: jbmessaging-375.patch, patch-JBMESSAGING-375.txt
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> We should add an ability to group messages by JMSXGroupID, so any messages with the same group id always go to the same consumer on a queue.
> This would be useful when having competing consumers on a queue and you want each consumer to handle all messages with a particular value of JMSXGroupID
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (GPD-156) GenericElementXmlAdapter doesnt add child nodes
by Imran Naqvi (JIRA)
GenericElementXmlAdapter doesnt add child nodes
-----------------------------------------------
Key: GPD-156
URL: http://jira.jboss.com/jira/browse/GPD-156
Project: JBoss jBPM GPD
Issue Type: Bug
Components: jpdl
Affects Versions: jBPM JPDL Designer 3.1.0.CR
Reporter: Imran Naqvi
Assigned To: Koen Aers
If you have a template such as:
<?xml version="1.0"?>
<process-definition name="Movie" version="11">
<start-state name="Start">
<transition to="Get MPEG Properties" />
</start-state>
<node name="Get MPEG Properties">
<action class="SomeActionHandler"><send>010901</send>
<keys>
<entry>
<key>VarName</key>
<value>1122</value>
</entry>
</keys>
<receive>
<element>030101</element>
<element>030102</element>
</receive>
</action>
<transition to="End"/> </node>
<end-state name="End" />
The nested Generic Elements arent added by the adapter. The reason for this is that the GenericElementXmlAdapter.doModelAdd() doesnt do anything. We need to add the following code to this method:
String type = child.getElementType();
SemanticElement jpdlElement;
jpdlElement = getSemanticElementFactory().createById("org.jbpm.gd.jpdl.genericElement");
child.initialize(jpdlElement);
GenericElement genericElement= (GenericElement )getSemanticElement();
genericElement.addGenericElement((GenericElement)jpdlElement);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBAOP-415) Advice Matching algorithm is ignoring generics
by Flavia Rainone (JIRA)
Advice Matching algorithm is ignoring generics
----------------------------------------------
Key: JBAOP-415
URL: http://jira.jboss.com/jira/browse/JBAOP-415
Project: JBoss AOP
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.alpha4
Reporter: Flavia Rainone
Assigned To: Flavia Rainone
Fix For: 2.0.0.alpha5
Advice Matching does not takes into account generic types; it is working with the old reflection API instead (Class instead of Type).
To modifiy this, we need to update code in classes:
- org.jboss.aop.advice.annotation.AdviceInfo
- org.jboss.aop.advice.annotation.AnnotatedParameterAdviceInfo
- org.jboss.aop.advice.AdviceMethodProperties
- joinpoint generators that pass the return, arguments and exception types to AdviceMethodProperties instances.
This includes updating the assignability degree algorithm of org.jboss.aop.advice.annotation package.
The methods for this task are partly written in org.jboss.test.aop.beforeafterArgs.ArgAspectGenerics.
Tests for generic return types are also necessary, and need to be written.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBMESSAGING-1101) Failure to deserialize BytesMessage contents
by Travis Brown (JIRA)
Failure to deserialize BytesMessage contents
--------------------------------------------
Key: JBMESSAGING-1101
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1101
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.0.GA
Environment: jboss-4.2.1.GA, jboss-remoting 2.2.2.SP1-brew, 7 node cluster
Reporter: Travis Brown
Assigned To: Tim Fox
BytesMessage consumers often receive the following error:
Client side:
2007-10-09 06:54:12,076 [WorkerThread#1[10.7.68.52:2209]] ERROR ServerThread - Worker thread initialization failure
java.io.EOFException
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:530)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
Server side:
2007-10-09 06:54:12,071 ERROR [org.jboss.jms.wireformat.JMSWireFormat] Failed to write packet
java.lang.RuntimeException: Unknown type: 76
at org.jboss.messaging.util.StreamUtils.readObject(StreamUtils.java:159)
at org.jboss.messaging.core.impl.message.MessageSupport.readPayload(MessageSupport.java:435)
at org.jboss.messaging.core.impl.message.MessageSupport.getPayload(MessageSupport.java:264)
at org.jboss.jms.message.JBossBytesMessage.getPayloadAsByteArray(JBossBytesMessage.java:592)
at org.jboss.messaging.core.impl.message.MessageSupport.write(MessageSupport.java:369)
at org.jboss.jms.message.JBossMessage.write(JBossMessage.java:1048)
at org.jboss.jms.wireformat.ClientDelivery.write(ClientDelivery.java:91)
at org.jboss.jms.wireformat.JMSWireFormat.write(JMSWireFormat.java:237)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:983)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:559)
at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.remoting.Client.invokeOneway(Client.java:598)
at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallback(ServerInvokerCallbackHandler.java:815)
at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallbackOneway(ServerInvokerCallbackHandler.java:686)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.performDelivery(ServerSessionEndpoint.java:1494)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.replicateDeliveryResponseReceived(ServerSessionEndpoint.java:1094)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.handleReplicateDeliveryAck(MessagingPostOffice.java:1274)
at org.jboss.messaging.core.impl.postoffice.ReplicateDeliveryAckMessage.execute(ReplicateDeliveryAckMessage.java:54)
at org.jboss.messaging.core.impl.postoffice.GroupMember$DataReceiver.receive(GroupMember.java:582)
at org.jgroups.JChannel.up(JChannel.java:1102)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:197)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.FC.up(FC.java:422)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:768)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:788)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:258)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:516)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:242)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:569)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:170)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.FD.up(FD.java:300)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:162)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.Discovery.up(Discovery.java:225)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:908)
at org.jgroups.protocols.TP.handleIncomingPacket(TP.java:850)
at org.jgroups.protocols.TP.access$400(TP.java:45)
at org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1296)
at java.lang.Thread.run(Thread.java:595)
In MessageSupport.getPayload(MessageSupport.java:264), if payload == null, it attempts to deserialize the byte array, which in this case is the content of the BytesMessage. StreamUtils.readObject(StreamUtils.java:159) will report "Unknown type" followed by the value of the first byte of the BytesMessage payload. (This could be misinterpreted during deserialization if the first byte happens to match a constant.)
I am not sure how to recreate the test case yet (payload is perhaps typically non-null), but it happens frequently in our environment, where the BytesMessage is 95% of the traffic.
This fix resolves the issue in our environment:
diff -r org/jboss/jms/message/JBossBytesMessage.java
592c592
< return (byte[])getPayload();
---
> return (byte[])getBytesMessagePayload();
diff -r org/jboss/messaging/core/impl/message/MessageSupport.java
281a282,303
> public synchronized Object getBytesMessagePayload()
> {
> if (payload != null)
> {
> return payload;
> }
> else if (payloadAsByteArray != null)
> {
> payload = payloadAsByteArray;
> payloadAsByteArray = null;
> return payload;
> }
> else
> {
> return null;
> }
> }
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBMESSAGING-1079) JBM should call BytesMessage.reset() before redelivery, or not redeliver the same message instance
by Julian Scheid (JIRA)
JBM should call BytesMessage.reset() before redelivery, or not redeliver the same message instance
--------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1079
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1079
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.0 CR3
Environment: $ java -version
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode)
The unit tests have been run using the postgresql provider with
Reporter: Julian Scheid
Assigned To: Tim Fox
Priority: Minor
Consider the following sequence of events:
- a durable subscriber subscribes to a topic with client acknowledgment
- a BytesMessage is sent to that topic
- the durable subscriber receives the message and reads its contents completely using BytesMessage.readBytes(byte[])
- the connection is closed without the subscriber acknowledging the message
- the subscriber re-subscribes and re-receives the message
- the subscriber re-reads the contents of the message using BytesMessage.readBytes(byte[])
In this situation, the second call to readBytes will not return any data (it will return -1 to indicate EOF and no data will be copied to the byte array passed in), unless the message is explicitly reset() by the client first.
This can be verified by the unit test that I am going to attach.
The JMS 1.1 specification isn't entirely clear on whether the provider is required to reset a message in this situation.
However, the spec says in section 3.9, "Access to Sent Messages":
"After sending a message, a client may retain and modify it without affecting
the message that has been sent. The same message object may be sent multiple
times. "
Here, I would interpret changing the BytesMessage's internal stream pointer as a side-effect of reading its data to be a modification.
Furthermore, the API docs for javax.jms.BytesMessage say
"The same message object can be sent multiple times. When a message has been received, the provider has called reset so that the message body is in read-only mode for the client."
(see http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/BytesMessage.html... )
This also sounds to me like a client could expect that the reset() method has been called when receiving it, regardless of whether it has been received before.
Even if I am misreading the spec and it is not the provider's responsibility to reset the message in the interim, there are clients out there (e.g. StompConnect - see my corresponding ticket at http://jira.codehaus.org/browse/STOMP-5) that do expect this behavior, and so in the spirit of the Robustness Principle ("Be conservative in what you do; be liberal in what you accept from others") I would suggest to implement this behavior regardless.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBAS-4855) jboss-web with 4.0 dtd does not deploy
by Thomas Diesler (JIRA)
jboss-web with 4.0 dtd does not deploy
--------------------------------------
Key: JBAS-4855
URL: http://jira.jboss.com/jira/browse/JBAS-4855
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Assigned To: Alexey Loubyansky
Fix For: JBossAS-5.0.0.Beta3
[tdiesler@tddell trunk]$ ant -Dtest=org.jboss.test.ws.jaxws.samples.context.WebServiceContextJSETestCase one-test
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to resolve schema nsURI= location=http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:153)
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:71)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:86)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:223)
... 66 more
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve schema nsURI= location=http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd
at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:306)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:402)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:199)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBAS-4857) NPE in ContainerConfigurationMetaDataWrapper
by Thomas Diesler (JIRA)
NPE in ContainerConfigurationMetaDataWrapper
--------------------------------------------
Key: JBAS-4857
URL: http://jira.jboss.com/jira/browse/JBAS-4857
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Assigned To: Scott M Stark
[tdiesler@tddell trunk]$ ant -Dtest=org.jboss.test.ws.benchmark.jaxrpc.BenchmarkDocEJBTestCase one-test
getContainerConfigurations returns null
configurationsWrapper = new ContainerConfigurationsMetaDataWrapper(primary.getContainerConfigurations(),
defaults.getContainerConfigurations());
Caused by: java.lang.NullPointerException
at org.jboss.metadata.ejb.jboss.ContainerConfigurationsMetaDataWrapper.<init>(ContainerConfigurationsMetaDataWrapper.java:60)
at org.jboss.metadata.ejb.jboss.JBossMetaDataWrapper.<init>(JBossMetaDataWrapper.java:57)
at org.jboss.deployment.JBossEjbParsingDeployer.parse(JBossEjbParsingDeployer.java:104)
at org.jboss.deployment.JBossEjbParsingDeployer.parse(JBossEjbParsingDeployer.java:44)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months