[JBoss JIRA] (JGRP-1564) TP: passing messages up in batches
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 (was: TP: message batches)
> TP: passing messages up in batches
> ----------------------------------
>
> 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
11 years, 11 months
[JBoss JIRA] (AS7-6419) Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
by Martin Keller (JIRA)
Martin Keller created AS7-6419:
----------------------------------
Summary: Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
Key: AS7-6419
URL: https://issues.jboss.org/browse/AS7-6419
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.2.0.Alpha1
Environment: Configuration:
JDK-Version: 1.6.0_33
Operating System: Windows 7 (32 Bit)
JBoss Application Server jboss-as-7.2.0.Alpha1-SNAPSHOT (build Dec. 19th 2012)
JDK-Version: 1.6.0_33
Resource Adapter: BeanConnect 3.0 developed by our Company (Fujitsu)
Reporter: Martin Keller
Assignee: Jesper Pedersen
Tbis Problem was reported before see https://issues.jboss.org/browse/AS7-6384, but now the components to reproduce it is included.
Starting an application using our JCA 1.6 resource adapter fails with
java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
It works ok in the JBoss JCA 1.5 environment and on other application servers with JCA1.6 environment:
GlassFish OS Edition 3, IBM WebSphere 8.0 and WebLogic 12.
Questions:
What could be the cause for this exception?
Can we switch off the validation?
What is missing to run the validation successful?
Details:
The full stack is:
15:04:02,128 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool – 64) MSC00001: Failed to start service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_33]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:177)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
... 7 more
Caused by: javax.resource.ResourceException: IJ000852: Validation exception
at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:147)
at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:175)
... 8 more
Caused by: javax.validation.ValidationException: Unable to find a default provider
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264) [validation-api-1.0.0.GA.jar:]
at org.jboss.jca.core.bv.BeanValidationUtil.createValidatorFactory(BeanValidationUtil.java:51)
at org.jboss.jca.core.bv.BeanValidationUtil.createValidator(BeanValidationUtil.java:63)
at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:135)
... 9 more
--
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
11 years, 11 months
[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
by Bernd Koecke (JIRA)
[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ]
Bernd Koecke commented on AS7-6408:
-----------------------------------
Hello Tomaz,
I changed my script and now also the new way is working perfectly.
Thanks a lot,
Bernd
> Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
> ---------------------------------------------------------------------------
>
> Key: AS7-6408
> URL: https://issues.jboss.org/browse/AS7-6408
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.2.0.Alpha1
> Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013)
> Reporter: Bernd Koecke
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
> Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml
>
>
> When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment.
> When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script.
--
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
11 years, 11 months
[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
by Bernd Koecke (JIRA)
[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ]
Bernd Koecke closed AS7-6408.
-----------------------------
All is working fine :).
> Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
> ---------------------------------------------------------------------------
>
> Key: AS7-6408
> URL: https://issues.jboss.org/browse/AS7-6408
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.2.0.Alpha1
> Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013)
> Reporter: Bernd Koecke
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
> Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml
>
>
> When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment.
> When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script.
--
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
11 years, 11 months
[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar edited comment on AS7-6408 at 1/30/13 8:06 AM:
-----------------------------------------------------------
Yeah fix also addresses that.
news for 7.2 is that you now have both :add-protocol and :add-transport operations that replace lists parameters that ware part of add() operation
but in any case I would modify your script to something like that:
{noformat}
# Configuring jGroups
batch
/extension=org.jboss.as.clustering.jgroups:add
run-batch
batch
/subsystem=jgroups:add(default-stack=udp)
# protocols is a list of string now. I have to configure socket-bindings later
/subsystem=jgroups/stack=udp:add()
/subsystem=jgroups/stack=udp/transport=TRANSPORT:add("type"=>"UDP","socket-binding"=>"jgroups-udp")
/subsystem=jgroups/stack=udp:add-protocol("type"=>"FD_SOCK","socket-binding"=>"jgroups-udp-fd")
... (other protocols)...
/subsystem=jgroups/stack=tcp:add()
/subsystem=jgroups/stack=tcp/transport=TRANSPORT:add("type"=>"TCP","socket-binding"=>"jgroups-tcp")
/subsystem=jgroups/stack=tcp:add-protocol("type"=>"MPING","socket-binding"=>"jgroups-mping")
/subsystem=jgroups/stack=tcp:add-protocol("type"=>"pbcast.NAKACK2")
... (other protocols)...
run-batch
{noformat}
was (Author: ctomc):
Yeah fix also addresses that.
news for 7.2 is that you now have both :add-protocol and :add-transport operations that replace lists parameters that ware part of add() operation
but in any case I would modify your script to something like that:
{noformat}
# Configuring jGroups
batch
/extension=org.jboss.as.clustering.jgroups:add
run-batch
batch
/subsystem=jgroups:add(default-stack=udp)
# protocols is a list of string now. I have to configure socket-bindings later
/subsystem=jgroups/stack=udp:add()
/subsystem=jgroups/stack=udp:add-transport("type"=>"UDP","socket-binding"=>"jgroups-udp")
/subsystem=jgroups/stack=udp:add-protocol("type"=>"FD_SOCK","socket-binding"=>"jgroups-udp-fd")
... (other protocols)...
/subsystem=jgroups/stack=tcp:add()
/subsystem=jgroups/stack=udp:add-transport("type"=>"TCP","socket-binding"=>"jgroups-tcp")
/subsystem=jgroups/stack=udp:add-protocol("type"=>"MPING","socket-binding"=>"jgroups-mping")
/subsystem=jgroups/stack=udp:add-protocol("type"=>"pbcast.NAKACK2")
... (other protocols)...
run-batch
{noformat}
> Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
> ---------------------------------------------------------------------------
>
> Key: AS7-6408
> URL: https://issues.jboss.org/browse/AS7-6408
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.2.0.Alpha1
> Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013)
> Reporter: Bernd Koecke
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
> Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml
>
>
> When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment.
> When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script.
--
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
11 years, 11 months
[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar commented on AS7-6408:
----------------------------------
Hi,
I miss-read the code for adding transport. proper syntax is:
{noformat}
/subsystem=jgroups/stack=<stack-name>/transport=TRANSPORT:add(all the options you need)
{noformat}
hope this helps
> Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
> ---------------------------------------------------------------------------
>
> Key: AS7-6408
> URL: https://issues.jboss.org/browse/AS7-6408
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.2.0.Alpha1
> Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013)
> Reporter: Bernd Koecke
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
> Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml
>
>
> When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment.
> When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script.
--
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
11 years, 11 months
[JBoss JIRA] (JGRP-1540) TP: simplified message bundler
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1540?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1540:
--------------------------------
Make sure to send batches of 1 as *single* messages
> TP: simplified message bundler
> ------------------------------
>
> Key: JGRP-1540
> URL: https://issues.jboss.org/browse/JGRP-1540
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> Instead of maintaining a hashmap (like for the current bundlers), a simple blocking bounded queue of messages would be used. Whenever we've reached M bytes or N milliseconds have elapsed, a consumer thread processes the queue in the following manner:
> * First set the queue to a new queue (volatile assignment), reuse a number of queues
> * Iterate through all messages in the current queue, for each message:
> ** If the destination is the same as the current destination, write the message to the stream for the current destination
> ** Else set the current destination to msg.getDest() and create an output stream (similar to writing a message list)
> *** Stream the current message to the output stream
> *** If there was a previous destination, close the associated output stream and send the message list
> Example:
> * We have messages with the following destinations: A, null, null, B, B, null, A, null, null, null
> * First we send a message list consisting of 1 message to A
> * Next we send a message list consisting of 2 messages to the cluster (dest==null)
> * Then we send a batch of 2 messages to B, 1 to the cluster, 1 to A and 3 to the cluster
--
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
11 years, 11 months
[JBoss JIRA] (AS7-6410) Session beans are not bound to JNDI if there is a remote interface for a stateless bean
by Jari Juslin (JIRA)
[ https://issues.jboss.org/browse/AS7-6410?page=com.atlassian.jira.plugin.s... ]
Jari Juslin commented on AS7-6410:
----------------------------------
Is there any known workaround to make remote calls to stateless session beans work with 7.1.1?
> Session beans are not bound to JNDI if there is a remote interface for a stateless bean
> ---------------------------------------------------------------------------------------
>
> Key: AS7-6410
> URL: https://issues.jboss.org/browse/AS7-6410
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Naming, Remoting
> Affects Versions: 7.1.1.Final
> Environment: Ubuntu 12.10
> Reporter: Jari Juslin
> Assignee: jaikiran pai
> Attachments: bugrepro.zip
>
>
> I have a session bean inside a jar, which in turn is inside an ear. If the session bean's interface is market with @Remote, JBoss 7.1.1 does not bind any beans in the package to JNDI. Change the @Remote to @Local or comment it out and binding takes place.
> The binding was checked both programmatically and from JBoss Management Console.
> No errors messages are printed.
--
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
11 years, 11 months
[JBoss JIRA] (AS7-6410) Session beans are not bound to JNDI if there is a remote interface for a stateless bean
by Jari Juslin (JIRA)
[ https://issues.jboss.org/browse/AS7-6410?page=com.atlassian.jira.plugin.s... ]
Jari Juslin commented on AS7-6410:
----------------------------------
Confirming that by against the master it works. The last commit on the version that I tested is : c75a7ae8c13339e522f2dd85fcb0d2cca4c56a0b
> Session beans are not bound to JNDI if there is a remote interface for a stateless bean
> ---------------------------------------------------------------------------------------
>
> Key: AS7-6410
> URL: https://issues.jboss.org/browse/AS7-6410
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Naming, Remoting
> Affects Versions: 7.1.1.Final
> Environment: Ubuntu 12.10
> Reporter: Jari Juslin
> Assignee: jaikiran pai
> Attachments: bugrepro.zip
>
>
> I have a session bean inside a jar, which in turn is inside an ear. If the session bean's interface is market with @Remote, JBoss 7.1.1 does not bind any beans in the package to JNDI. Change the @Remote to @Local or comment it out and binding takes place.
> The binding was checked both programmatically and from JBoss Management Console.
> No errors messages are printed.
--
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
11 years, 11 months
[JBoss JIRA] (AS7-6410) Session beans are not bound to JNDI if there is a remote interface for a stateless bean
by Jari Juslin (JIRA)
[ https://issues.jboss.org/browse/AS7-6410?page=com.atlassian.jira.plugin.s... ]
Jari Juslin edited comment on AS7-6410 at 1/30/13 4:44 AM:
-----------------------------------------------------------
Confirming that against the master it works. The last commit on the version that I tested is : c75a7ae8c13339e522f2dd85fcb0d2cca4c56a0b
was (Author: zds):
Confirming that by against the master it works. The last commit on the version that I tested is : c75a7ae8c13339e522f2dd85fcb0d2cca4c56a0b
> Session beans are not bound to JNDI if there is a remote interface for a stateless bean
> ---------------------------------------------------------------------------------------
>
> Key: AS7-6410
> URL: https://issues.jboss.org/browse/AS7-6410
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Naming, Remoting
> Affects Versions: 7.1.1.Final
> Environment: Ubuntu 12.10
> Reporter: Jari Juslin
> Assignee: jaikiran pai
> Attachments: bugrepro.zip
>
>
> I have a session bean inside a jar, which in turn is inside an ear. If the session bean's interface is market with @Remote, JBoss 7.1.1 does not bind any beans in the package to JNDI. Change the @Remote to @Local or comment it out and binding takes place.
> The binding was checked both programmatically and from JBoss Management Console.
> No errors messages are printed.
--
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
11 years, 11 months