[JBoss JIRA] (AS7-5942) Implement custom Stack resource for JGroups to maintain protocol order
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-5942?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz updated AS7-5942:
-------------------------------------
Priority: Minor (was: Major)
> Implement custom Stack resource for JGroups to maintain protocol order
> -----------------------------------------------------------------------
>
> Key: AS7-5942
> URL: https://issues.jboss.org/browse/AS7-5942
> Project: Application Server 7
> Issue Type: Task
> Components: Clustering, Domain Management
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 7.2.0.Alpha1
>
>
> A JGroups stack is a transport together with an ordered list of protocols. The transport and the protocols are maintained as child resources. There is no direct way to maintain the order of a set of protocol child resources, so we need to implement a custom resource which does this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-5942) Implement custom Stack resource for JGroups to maintain protocol order
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-5942?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz reopened AS7-5942:
--------------------------------------
Tomaz, this issue was not done.
The custom resource was intended to define the protocol order, not as a read-only attribute as it is now, but rather as a field of the custom resource, hidden to the user. The order of the protocols will be visible to the user through the protocol children which will be returned in order.
Reopening, and this may need to be pushed forward.
> Implement custom Stack resource for JGroups to maintain protocol order
> -----------------------------------------------------------------------
>
> Key: AS7-5942
> URL: https://issues.jboss.org/browse/AS7-5942
> Project: Application Server 7
> Issue Type: Task
> Components: Clustering, Domain Management
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 7.2.0.Alpha1
>
>
> A JGroups stack is a transport together with an ordered list of protocols. The transport and the protocols are maintained as child resources. There is no direct way to maintain the order of a set of protocol child resources, so we need to implement a custom resource which does this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBMETA-363) Validation errors with "jboss-web_7_0.xsd
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/JBMETA-363?page=com.atlassian.jira.plugin... ]
Wolfgang Knauf commented on JBMETA-363:
---------------------------------------
"jboss-web_7_0.xsd" is not available on the jboss web site, so validation of the jboss-web.xml ist not possible because the XSD cannot be resolved. I could have added it to the Eclipse XML catalog, but I choose the other option of a local schemaLocation because it is the faster way ;-).
> Validation errors with "jboss-web_7_0.xsd
> -----------------------------------------
>
> Key: JBMETA-363
> URL: https://issues.jboss.org/browse/JBMETA-363
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: web
> Affects Versions: 7.0.5
> Environment: Eclipse
> Reporter: Wolfgang Knauf
> Assignee: Jean-Frederic Clere
>
> I tried to create a "jboss-web.xml" file based on the "jboss-web_7_1.xsd"
> As this is not uploaded to the web up to now, I created it with a schema location pointing to my local JBoss 7.2.0Alpha1 snapshot:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee file:///C:/Temp/jboss-as-7.2.0.Alpha1-SNAPSHOT/docs/schema/jboss-web_7_0.xsd"
> version="7.0">
> ...
> </jboss-web>
> Eclipse shows validation errors in the XSD file.
> The first on is:
> sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two
> occurences of 'http://java.sun.com/xml/ns/javaee,descriptionGroup'
> (occurs in javaee_6.xsd, line 88)
> And a lot more of those.
> The file was created as part of https://issues.jboss.org/browse/AS7-1262 - and the one who created it found the same validation error.
> It seems the fix is quite simple:
> "jboss-web_7_0.xsd" contains this import:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="web-app_3_0.xsd"/>
> Change it to:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"/>
> The reason seems to be: "jboss-web_7_0.xsd" imports "jboss-common_6-0.xsd", and this one imports "javaee_6.xsd" with a full schema location.
> The "web-app_3_0.xsd" in "jboss-web_7_0.xsd" has a local schema location, thus the "javaee_6.xsd" import in "web-app_3_0.xsd" points also to local.
> And this seems to cause a duplicate import of the file.
> (might also be an Eclipse valiation bug)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JGRP-1564) TP: passing messages up in batches (part I)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1564?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1564:
--------------------------------
In this JIRA, we're only implement batching in protocols up to and including NAKACK2 and UNICAST2. In part 2, we'll implement up(MessageBatch) in the remaining protocols *above* UNICAST2 and NAKACK2, and also in the JChannel and MessageDispatcher/RPCDispatcher/MessageCorrelator (if the latter need to implement something special to implement batching)
> TP: passing messages up in batches (part I)
> -------------------------------------------
>
> Key: JGRP-1564
> URL: https://issues.jboss.org/browse/JGRP-1564
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
> It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
> The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
> We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
> The unmarshalling shouldn't take long, so TP.receive() should return quickly.
> This approach would allow us to send OOB messages in message batches, too (currently not allowed).
> The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
> The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT, SIZE, FRAG(2) (if placed under UNICAST/NAKACK), COMPRESS etc. However, we could add another up(Batch) method, which by default (in Protocol):
> - removes all messages for a given protocol P (by P.ID)
> and calls up(Event.MSG, msg) for all messages in the batch
> - calls up_prot.up(batch) if the batch is not empty
> This would allow for all current protocols to continue working and only the protocols which don't check for headers and/or need special processing (such as UNICAST and NAKACK) would have to implement up(Batch).
> This solution would be better than introducing another event type MSG_BATCH, as not every protocol overriding up(Event) calls super.up(Event).
> However, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JGRP-1564) TP: passing messages up in batches (part I)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1564?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1564:
---------------------------
Summary: TP: passing messages up in batches (part I) (was: TP: passing messages up in batches)
> TP: passing messages up in batches (part I)
> -------------------------------------------
>
> Key: JGRP-1564
> URL: https://issues.jboss.org/browse/JGRP-1564
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
> It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
> The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
> We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
> The unmarshalling shouldn't take long, so TP.receive() should return quickly.
> This approach would allow us to send OOB messages in message batches, too (currently not allowed).
> The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
> The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT, SIZE, FRAG(2) (if placed under UNICAST/NAKACK), COMPRESS etc. However, we could add another up(Batch) method, which by default (in Protocol):
> - removes all messages for a given protocol P (by P.ID)
> and calls up(Event.MSG, msg) for all messages in the batch
> - calls up_prot.up(batch) if the batch is not empty
> This would allow for all current protocols to continue working and only the protocols which don't check for headers and/or need special processing (such as UNICAST and NAKACK) would have to implement up(Batch).
> This solution would be better than introducing another event type MSG_BATCH, as not every protocol overriding up(Event) calls super.up(Event).
> However, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6424) Web administration console does not handle values set with expressions
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/AS7-6424?page=com.atlassian.jira.plugin.s... ]
Heiko Braun commented on AS7-6424:
----------------------------------
yes, I'll do another spin
> Web administration console does not handle values set with expressions
> ----------------------------------------------------------------------
>
> Key: AS7-6424
> URL: https://issues.jboss.org/browse/AS7-6424
> Project: Application Server 7
> Issue Type: Bug
> Components: Console
> Affects Versions: 7.2.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Heiko Braun
> Labels: console_1.5.1
> Fix For: 7.2.0.Alpha1
>
>
> In case of using expression in standalone.xml then web admin console does not show the evaluated expression and instead of it 0 is shown. In other cases you can see error message of the web admin console saying "Failed to parse response".
> As I was testing the behavior of web administration console just on several places I can't talk about behaving of all subsystem.
> This was hit on ejb subsystem.
> You can try to set following tag like this
> {code}
> <strict-max-pool name="slsb-strict-max-pool" max-pool-size="${some.var:20}" instance-acquisition-timeout="${some.other.var}" instance-acquisition-timeout-unit="MINUTES"/>
> {code}
> In case of max-pool-size you'll see value 0 instead of 20 in the console. And nevertheless that you run the server with -Dsome.other.var=5 you'll see the parsing error because of the instance-acquisition-timeout attribute being set with expression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months