April 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Header key for scheduled message delivery should be defi

by timfox

MessageImpl is as core class, JBossMessage is a JMS layer class. We can't have core depend on JMS, however if you can think of a better place to put it fine. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225025#4225025 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225025

16 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: NPE in transaction commit

by timfox

"clebert.suconic(a)jboss.com" wrote : What about starting / getting a Arjuna on the example, and just use the TM's API instead of the XA's API. | | Isn't that what most users should be doing? We don't want to have to distribute the jboss jta jar with the distro View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225024#4225024 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225024

16 years, 12 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jpdl schema filename

by camunda

I would allow schema extensions in minor updates (4.1/4.2/...). Micro updates would be maybe too confusing? So I would prefer jpdl4.1.xsd I guess. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225008#4225008 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225008

16 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Large messages broken

by clebert.suconic＠jboss.com

There are leaks on the testsuite ATM. So far I didn't see anything that would affect production, but failing, stopping & starting servers is leaving some garbage out, what is eventually making it fail. The new code for some reason is making a "bigger user" of those leaks even thought the leaks were already there, already making it fail eventually.RemotingConnection.. etc. So far I have committed my code into a branch.. and I'm trying to cleanup some of those leaks a little bit. I will open another thread later after more investigation with some information about the leaks I have found. This post now is just to inform why I didn't commit the code on the main branch yet. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224964#4224964 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224964

16 years, 12 months

1
0
0 / 0

[Design of JBossCache] - Re: Evolution of TcpDelegatingCacheLoaders/TcpCacheServers

by akluge

I've been busy, but hopefully I can come back to this project now. I have started to build a prototype with MINA. Mostly I am focusing on a JBC binary protocol, however, handling additional protocols should flow naturally using features built into MINA. The primary access to the cache will be via a binary protocol. This provides for efficiency as well as extensibility. A Prototypical JBoss Cache Request Byte Description Byte 0 (0x90) JBoss Cache Request Marker ----------------------------------------------------------- Byte 1 Byte 2 A Java int containing the request type. Byte 3 Byte 4 ------------------------------------------------------------- Byte 5 . . Data specific to the request type. . Byte n The Initial Byte The initial byte marker serves two main purposes. First, it allows the parser to confirm that the currently read byte is the beginning of a JBoss cache binary request. Secondly, a JBoss Cache MessageDecoder (A MINA MessageDecoder) can check the value of this byte in its decodable method and return true only if the byte matches the 0x90 JBoss Cache request marker. If the JBoss Cache MessageDecoder is used within a DemuxingProtocolDecoder (another MINA class) along with, say, a memcached MessageDecoder, the server can identify the protocol used in each request by examining the lead byte, and invoke the appropriate message decoder. Likely values for the first byte identifying the protocol. Value Meaning 0x80 memcached binary request 0x81 memcached binary response 0x90 JBoss Cache binary request 0x91 JBoss Cache binary response The Message Type The next field is a java int written into four bytes of the message. This identifies the specific type of message. It is used in a RequestDecoder (another standard MINA class) class to select the appropriate builder for the request. Data Specific to the Message Type The builder reads the remainder of the input stream, and constructs a Request object, which will be passed in to the IoHandler where it will carry out the expected actions on the cache. Right now, I am working through an implementation of a single test flow to be sure that the plumbing can generally work. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224947#4224947 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224947

16 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Large messages broken

by clebert.suconic＠jboss.com

anonymous wrote : That test fails very ocassionally on Hudson. Actually it fails very frequent. Set the numIterations=100, and run any of the MultiThreadFailoverTests... You will get hangs and failures. That's something to be seen on next week :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224921#4224921 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224921

16 years, 12 months

1
0
0 / 0

[Design of Security on JBoss] - Re: java security in jboss & runtime parsing of java.policy

by baranowb

at runtime or after container starts we have to deploy multiple deployable units (DU - just an abstraction). each component from DU may have element in its descriptor (which we parse and it is available as POJO) which contains string formatted accordingly to rules of policy.file. Now upon deploying component we need to load those policies, when component is undeployed we have to remove them. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224919#4224919 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224919

16 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: NPE in transaction commit

by clebert.suconic＠jboss.com

What about starting / getting a Arjuna on the example, and just use the TM's API instead of the XA's API. Isn't that what most users should be doing? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224917#4224917 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224917

16 years, 12 months

1
0
0 / 0

[Design of JBoss jBPM] - jpdl schema filename

by tom.baeyens＠jboss.com

for the jpdl schema file name, what is the best naming strategy ? jpdl.xsd jpdl4.xsd jpdl4.1.xsd what kind of schema changes are allowed inbetween minor and micro version updates ? opinions ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224913#4224913 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224913

16 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Large messages broken

by clebert.suconic＠jboss.com

> Other tests fail more frequently on HUdson, e.g. paging multithread failover test. I have looked that one.. it is https://jira.jboss.org/jira/browse/JBMESSAGING-1558. Right now, the testsuite fails very frequently on failover tests in my box... with or without my changes. But it frequently pass if I run only the failover tests. There is some leak somewhere probably. I suspect (pure guess) about those *FileStorageTest as the failover tests will run after those. I will run the failover tests with a big number of iterations to make sure I'm not creating any failures. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224906#4224906 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224906

16 years, 12 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 April 2009